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PREFACE 


This  report  details  the  story  of  a  Small  Business  Innovation  Research  (SBIR)  effort  that 
epitomizes  the  very  purpose  and  intended  results  of  the  SBIR  Program,  which  was  established  by 
Congress  under  the  Small  Business  Innovation  Development  Act  of  1982  and  reauthorized  under 
the  Small  Business  Research  and  Development  Enhancement  Act  of  1992.  As  a  direct  result  of 
SBIR  funds  provided  for  this  effort,  Quality  Decision  Management,  Inc.  (QDM)  successfully 
developed  important,  innovative  technology  in  an  emerging,  exciting  new  market  and  was 
successful  in  commercializing  the  resulting  technology  for  sale  to  businesses  worldwide.  In  effect, 
QDM  conducted  and  subsidized  a  Phase  m  effort  in  parallel  with  the  Air  Force-sponsored  Phase 
n  effort  to  produce  Quality  At  Work,  the  first  workflow-enabled  software  application  for  the 
groupware  market. 

Needless  to  say,  a  successful  effort  such  as  this  one  would  not  be  possible  without  the  strong 
commitment,  active  support,  and  insightful  vision  of  our  project  sponsors  and  technology 
partners.  This  fact  is  particularly  true  in  our  case,  as  our  effort  began  at  the  earliest  stage  of  a 
totally  new  market.  In  addition  to  facing  the  expected  technological  challenges,  we  found 
ourselves  in  continual  debate  with  pragmatists  and  skeptics  waiting  on  the  sidelines  to  see  if  this 
so-called  new  market  was  going  to  materialize  and  gain  popular  acceptance.  As  a  result,  we  are 
especially  grateful  to  the  partners  who  believed  in  our  efforts  and  helped  to  make  them  so 
successful. 

QDM  would  like  to  acknowledge  Matthew  C.  Tracy,  our  Project  Engineer  who  served  as  a 
constant  supporter  throughout  the  entire  effort.  We  would  also  like  to  acknowledge  the  series  of 
Technical  Monitors  -  Major  Louis  Szabo,  Capt.  Douglas  Armstrong,  JoLynn  Anderson,  and 
Lt.  Timothy  Townsend  -  who  believed  in  our  work  and  helped  to  make  sure  the  technology  was 
used. 

Other  technology  partners  who  are  helping  to  build  the  emerging  group  computing  market  have 
been  extremely  supportive  of  this  effort.  QDM  is  particularly  indebted  to  Lotus  Development 
Corporation  and  Action  Technologies,  Inc.  for  their  recognition  of  our  ideas  and  their 
contribution  of  outstanding  technology  components  that  have  made  this  effort  possible. 

There  are  two  people  without  whom  this  effort  would  not  be  possible.  The  first  is  Col.  Joseph  N. 
Kruppa,  who  understood  the  breakthrough  opportunities  of  QDM's  proposed  technology  and 
made  sure  we  were  able  to  march  forward.  Finally  most  important  is  Col  (Ret.)  Robert  Rissell, 
the  "founder"  and  first  director  of  the  FACTS  Office,  a  true  visionary  who  believed  in  the  ideas  of 
a  couple  of  young,  excited  entrepreneurs. 
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GROUPWARE  SYSTEM  FOR  MULTIDISCIPLINARY 
PARTICIPATION  FINAL  REPORT 

SUMMARY 

Quality  Decision  Management,  Inc.  (QDM),  in  our  Small  Business  Innovation  Research  (SBIR) 
effort  entitled  "Groupware  System  for  Multidisciplinary  Participation”  set  out  to  develop  a 
methodology  and  information  architecture  that  supports  multidisciplinary  participation  and 
communication  for  a  geographically  distributed  community  of  individuals  and  workgroups.  The 
goal  for  the  system  was  to  create  an  automated  environment  —  based  on  management  methods 
and  workgroup  technologies  —  that  would  improve  the  effectiveness  of  workgroup 
communication  and  coordination,  increase  awareness  of  processes  and  improve  the  efficiency  of 
their  execution,  and  provide  users  with  feedback  and  status  metrics. 

Through  the  course  of  this  effort,  QDM  has  defined  for  the  first  time  the  discipline  of 
Management  Technology.  We  have  pioneered  efforts  in  this  field,  developing  innovative 
technolo^es  that  bridge  the  gap  between  the  theories  of  management  science  and  the  practical 
concerns  of  everyday  business.  Thus,  the  effort  had  a  dual  emphasis;  inventing  and  integrating 
innovative  technologies  and  implementing  proven  management  methods  into  these  technologies 
so  corporate  cultures  would  embrace  both  the  groupware  system  and  the  methodology  embedded 
in  it.  As  a  result  of  this  dual  emphasis,  the  conclusions  and  observations  resulting  from  our  three 
years  of  research  and  development  have  as  much  to  do  with  cultural  and  organizational  effects  as 
with  technical  feasibility  and  software  development.  From  both  perspectives,  this  effort  has  been 
an  unqualified  success. 

Measured  in  terms  of  the  original  technological  goal,  as  stated  in  QDM’s  Phase  II  proposal,  we 
have  successfully  developed  a  “group-oriented  software  system  ...  to  support  multidisciplinary 
participation  and  collaboration  ...  to  promote  continuous  improvement  of  both  products  and 
processes,”(Quality  Decision  Management,  199 Id).  The  effort  has  produced  software  technology 
which  enables  groups  of  people  to  work  together  electronically,  to  visually  examine  a  distributed 
network  of  processes  to  track  the  work  being  done,  and  to  execute  plans  to  continually  improve 
the  results  of  the  work.  As  further  evidence  of  the  success  of  this  effort,  QDM  has  extended  the 
resulting  core  technology  of  the  workflow  module  of  the  effort  to  develop  and  market  a 
successful  commercial  software  product  called  Quality  At  Work®  (QAW). 

A  good  deal  of  the  success  of  this  product  is  attributable  to  QDM’s  realizations  about  the 
spectrum  of  workflow  technology  at  the  beginning  of  this  effort.  The  fact  that  these  realizations 
led  to  the  development  and  application  of  ad-hoc  workflow  tools  and  the  expansion  of  the 
workflow  spectrum  to  include  all  types  of  processes,  from  the  most  structured  to  the  most 
ad-hoc,  also  contributed  to  the  success.  With  our  recognition  and  use  of  this  new  type  of 
workflow  came  the  realization  of  the  criticality  of  successfully  matching  the  type  of  workflow 
solution  to  the  organization’s  culture  and  processes. 
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In  addition  to  these  technological  lessons,  we  have  learned  a  great  deal  about  teams  and  the 
challenge  of  implementing  brealcthrough  technology  in  an  organization.  We  believe  that  our 
conclusions  derived  from  the  organizational  impact  of  the  technology  are  as  important  as  those 
derived  from  the  technology  itself  During  the  course  of  this  research  effort,  we  clearly  observed 
that  simply  using  breakthrough  technology  does  not  guarantee  fundamental  changes  or 
productivity  improvements  in  the  way  people  work  together.  Automation  can  facilitate 
workgroup  productivity,  but  to  fully  appreciate  the  benefits  of  the  technology  requires  a 
commitment  to  change  and  learning  in  the  organization.  In  the  final  analysis,  the  technology 
cannot  drive  the  organization  but,  rather,  must  meet  the  needs  of  the  organizational  culture. 

INTRODUCTION 

Purpose  of  the  Effort 

Quality  Decision  Management,  Inc.  originally  submitted  a  proposal  in  response  to  a  topic  entitled 
Concurrent  Engineering  (CE)  which  appeared  in  Department  of  Defense  (DoD)  SBIR 
Solicitation  90. 1  for  Fiscal  Year  1990  (FY90).  The  original  topic  as  stated  in  the  AF90-063 
solicitation  was  to  “develop  information  architectures  and  new  applications  of  decision  science 
methodology  within  a  concurrent  engineering  environment.” 

The  intent  of  the  topic  as  described  in  the  solicitation  was  to  exploit  the  potential  benefits  of 
concurrent  engineering  in  two  ways. 

♦  Through  development  of  information  architectures,  tools,  and  methodologies  to  provide 
the  data  integration  and  communication  required  in  a  CE  environment.  The  goal  of 
these  information  architectures  is  to  facilitate  the  sharing  of  data  and  allow  horizontal 
and  vertical  design  parameter  tradeoffs. 

♦  Through  design  and  new  application  of  decision  support  tools  which  will  allow  teams  to 
examine  design  attributes  such  as  performance,  cost,  schedule,  supportability, 
operability,  and  producibility. 

After  successfully  completing  Phase  I  of  this  effort,  by  researching  and  designing  an  information 
architecture  that  would  meet  these  criteria,  QDM,  with  sponsorship  from  the  Acquisition 
Logistics  Branch  of  the  Armstrong  Laboratory  Logistics  Research  Branch  (AL/HRGA),  was 
awarded  Phase  II  contract  number  F41624-92-C-5006. 

The  purpose  of  the  Phase  II  effort  was  to  develop,  by  integrating  pieces  of  proven  technology  into 
a  value-added  product  that  could  be  practically  and  specifically  applied,  the  process-oriented 
group  support  system  we  had  designed  in  Phase  I. 

At  the  beginning  of  this  effort  nearly  four  years  ago,  QDM  recognized  that  trends  in  information 
technology  and  management  science  were  converging  on  the  notion  of  improving  workgroup 
communication,  collaboration,  and  productivity.  New  computer  hardware  and  software  was 


focusing  more  on  the  dynamics  of  integrated  workgroups  than  on  the  isolated  individual  desktop 
Management  theories  were  addressing  the  rate  and  magnitude  of  change  being  necessitated  by 
leaner,  more  agile,  more  geographically  distributed  workgroups  and  organizations.  QDM  saw  the 
potential  benefits  of  combining  these  two  concepts,  using  the  emerging  technologies  as  a  means  to 
implement  the  theories.  The  reason  behind  QDM’s  Phase  II  effort  was  to  develop  and  implement 
a  system  that  would  help  organizations  realize  these  benefits. 

The  Period  of  Performance  for  the  Phase  11  effort  was  June,  1992,  through  February,  1994.  This 
Final  Report  details  our  SBIR  Phase  11  efforts  and  the  technological  and  methodological  findings 
and  conclusions  that  they  produced. 

Subject  and  Scope  of  the  Effort 

Based  on  the  initial  SBIR  solicitation,  QDM  set  out  to  come  up  with  a  software  system  that 
would  allow  for  and  facilitate  the  process  of  CE.  CE  was  a  breakthrough  that  recognized  the 
power  of  parallel  performance  of  processes  across  functional  disciplines.  Cross-functional, 
multidisciplinary  processes  had  traditionally  been  performed  serially,  with  bundles  of  responsibility 
being  passed  from  department  to  department  as  the  process  progressed 

QDM’s  goal  in  this  effort  was  to  develop  a  methodology  and  information  architecture  that 
supports  multidisciplinary  participation  and  communication  in  parallel  for  a  geographically 
distributed  community  of  individuals  and  workgroups.  The  goal  for  the  system  was  an  automated 
environment,  based  on  management  methods  and  workgroup  technologies,  that  would  improve 
the  effectiveness  of  workgroup  communication  and  coordination,  increase  awareness  of  processes 
and  improve  the  efficiency  of  their  execution,  and  provide  users  with  feedback  and  status  metrics 
with  which  to  gauge  their  performance. 

To  better  understand  the  subject  and  scope  of  this  effort,  it  would  be  useful  to  learn  some 
background  information  about  the  technology  involved,  about  the  theory  behind  the  development 
of  this  genre  of  technology,  and  some  historical  background  about  QDM’s  Phase  I  SBIR  effort. 

Teamwork:  A  Communication-  and  Coordination-Intensive  Endeavor 

Without  communication,  effective  teamwork  is  impossible.  For  years,  technologies  have  been 
emerging  to  facilitate  and  improve  communication.  In  a  global  economy  made  up  of 
geographically  distributed  organizations,  departments,  and  business  alliances,  face-to-face  (“same 
time/same  place”)  communication  is  increasingly  difficult  to  organize  Such  basic  technologies  as 
telephones,  voice-mail,  and  fax  machines  are  designed  to  combat  this  phenomenon  and,  indeed, 
are  effective  ways  of  communicating  with  others  across  barriers  of  time  or  distance. 

However,  there  is  more  to  teamwork  than  “one-to-one”  communication  across  telephone  lines. 
True  collaboration  requires  multi-disciplinary,  “many-to-many”  communication  such  as 
brainstorming,  consensus  building,  and  focus  group  discussions  to  effectively  coordinate  the 
efforts  of  cross-functional  teams.  This  coordination  is  the  element  that  puts  the  work  in 
teamwork. 
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Telephone  conference  calls  are  one  way  to  facilitate  this  “many-to-many”  communication. 
However,  a  conference  call  requires  intensive  planning.  All  parties  must  be  available  at  the  same 
time  in  order  for  the  call  to  take  place.  In  today’s  fast-paced,  dynamic  business  world,  gathering 
people  for  a  conference  call  can  be  as  difficult  as  organizing  a  face-to-face  meeting  around  a 
conference  table!  The  true  breakthrough  for  effective  teamwork  would  be  a  means  to  facilitate 
this  “many-to-many”  communication  and  collaboration  without  requiring  that  all  parties  be 
gathered  together  at  the  same  time  or  in  the  same  place.  QDM  realized  that  this  was  a  significant 
technological  opportunity  and  was  awarded  an  SBIR  grant  to  pursue  a  breakthrough  system  that 
would  foster  and  facilitate  “many-to-many,”  “different  time/different  place”  communication, 
collaboration,  and  coordination,  as  illustrated  in  Figure  1 . 
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Figure  1 

The  goal  of  the  workflow-anahled  SBIR  system  is  to  foster  and 
facilitate  “many-to-many",  “different  time/different  place" 
communication,  collaboration,  and  coordination. 

The  Evolution  of  Software  Technologies:  Groupware  and  Workflow 

Recognizing  the  criticality  of  effective  communication  to  the  achievement  of  teamwork  in  today’s 
distributed  business  environments,  QDM  adopted  the  notion  that  an  effective  management 
strategy  must  include  modification  of  the  communications  infrastructure.  In  most  every  business 
today,  the  communications  infrastructure  is  composed  of  computer  technology.  Thus,  modifying 
this  infrastructure  is  fairly  simple  —  one  need  only  take  advantage  of  the  technological  advances 
being  made  in  the  computer  industry. 

The  software  industry  has  been  moving  steadily  toward  providing  tools  that  would  enable  the 
“many-to-many,”  “different  time/different  place”  communications  paradigm.  In  the  I980’s, 
Personal  Computers  and  software  packages  were  focused  on  increasing  the  productivity  of 
individual  users  and  the  quality  of  their  work.  Spreadsheet  programs,  word  processing  packages, 
and  presentation  software  made  individual  tasks  easier.  Software  has  recently  emerged  that  is 
doing  for  entire  workgroups  what  the  software  of  the  80’ s  did  for  individuals.  Such  group-related 
tasks  as  tracking  client  relationships,  processing  HelpDesk  requests,  and  managing  projects  are 
being  automated  with  tools  that  are  focused  on  workgroup  productivity 


Of  course,  streamlining  the  efforts  of  an  entire  workgroup  is  significantly  more  challenging  than 
checking  a  memo  for  spelling  mistakes.  This  new  generation  of  software  tools  must  handle  much 


more  than  simple  clerical  jobs;  it  must  help  entire  groups  work  together  and  coordinate  effort. 

The  first  step  in  the  coordination  process  is  improved  communication.  Electronic  mail  (E-mail) 
technology  met  this  challenge,  providing  networked  users  with  the  ability  to  communicate  with 
one  another  (“one-to-one”  communication),  or  to  broadcast  information  to  many  others 
(“one-to-many”  communication),  even  across  geographically  disparate  sites 

The  advent  of  Groupware  technology  has  taken  the  E-Mail  conununication  concept  several  steps 
fiiither;  it  allows  geographically  distant  users  not  only  to  send  and  receive  messages  but  to  share 
information  in  bulletin-board  style  discussion  forums  (“many-to-many”  communication).  People 
are  able  to  profit  firom  the  shared  information  contained  in  these  discussion  forums,  thus 
effectively  collaborating  with  their  co-workers  across  the  network.  As  the  number  of  these 
groupware  forums  flourish  and  multiply,  it  has  become  increasingly  difficult  for  users  to  browse, 
and  effectively  participate  in,  all  of  the  available  discussions. 

Workflow  automation  helps  users  manage,  organize,  and  act  on  the  wealth  of  shared  information 
made  available  by  the  groupware  environment.  It  adds  coordination  to  the  existing 
communication  and  collaboration  capabilities  of  software  and  has  the  power  to  make  existing 
groupware  applications  more  proactive  by  bringing  pertinent  information  to  the  attention  of  the 
appropriate  people  and  automating  and  tracking  processes  to  ensure  that  work  gets  done.  It  adds 
the  coordination  layer  to  the  “many-to-many”  communication  capabilities  of  Groupware,  as 
shown  in  Figure  2. 


Figure  2 

Workflow  adds  the  coordination  layer  to  the  “one-to-one" 
communication  of  E-mail  and  to  the  “many-to-many” 
communication/collaboration  of  Groupware 

Such  technologies  as  Groupware  and  workflow  are  continually  being  created  and  refined  because 
people  recognize  that  the  greatest  barriers  to  teamwork  have  often  proven  to  be  logistical, 
organizational,  and  geographical  in  nature.  Groupware  and  workflow,  as  their  names  suggest, 
overcome  these  barriers  to  teamwork  by  maximizing  the  efficiency  with  which  workgroups 
perform  processes  and  manage  the  flow  of  work  within  and  between  them. 

Groupware  and  workflow  technologies  enable  the  type  of  multidisciplinary  communication  and 
participation  that  QDM  sought  for  its  baseline  information  architecture.  In  its  Phase  II 
development  effort,  QDM  chose  to  reap  the  benefits  of  a  workflow-enabled  Groupware  platform. 
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using  and  enhancing  it  in  order  to  achieve  the  desired  result  of  improved,  cross-functional 
teamwork  that  addresses  specified  business  objectives. 

The  Evolution  of  a  New  Discipline:  Defining  Management  Technology 

Just  as  the  advent  of  Groupware  has  led  to  integrated  cross-functional  teams,  the  new  discipline 
of  Management  Technology,  a  term  coined  by  QDM  during  the  course  of  this  effort,  is  integrating 
the  once-disparate  concepts  of  software  technology  and  management  methodology.  Figure  3 
shows  an  illustration  of  the  merging  of  the  two  disciplines.  Groupware,  the  software  that  enabled 
multidisciplinary  teamwork,  is  itself  now  integrated  with  a  formerly  unrelated  discipline.  This 
merging  is  consistent  with  the  notion,  expressed  and  explained  above,  that  a  business’ 
management  strategy  must  be  interwoven  with  its  technological  and  communications 
infrastructures. 
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Figure  3 

Management  Technology  is  the  synergy  of  two  crucial  components  of  business.  It  enables: 
1.  Management  Methods  to  Leverage  Existing  and  Emerging  Technology 
2.  Software  Technology  to  Facilitate  the  Implementation  of  Management  Methods 

The  combination  of  software  technology  with  management  methodology  has  proven  to  be 
powerful  indeed,  leveraging  the  benefits  of  each  concept  to  create  a  unified  entity  that  is  greater 
than  the  sum  of  its  parts.  Management  Technology  bridges  the  gap  between  abstract 
methodological  theories  and  the  practical  concerns  of  everyday  business.  It  makes  software 
technology  the  vehicle  that  delivers  the  promised  benefits  of  management  methodologies.  “Best 
practices”  are  embedded  in  the  technology  that  people  use  every  day,  increasing  both  the 
functionality  of  the  software  and  the  practicality  of  the  theories  it  embodies. 

The  focus  of  our  research  and  development,  then,  is  on  using  existing  and  emerging  technologies 
not  simply  to  automate  collaborative  processes,  but  to  continue  to  define,  improve,  and  enhance 
them. 

Historical  Background:  Quality  Decision  Management’s  Phase  I  Effort 

This  research  effort  began  almost  four  years  ago  when  QDM  submitted  a  proposal  in  response  to 
a  topic  entitled  Concurrent  Engineering,  which  appeared  in  the  DoD  SBIR  Program  Solicitation 
90. 1  for  FY90.  QDM’s  proposal  title  was  Integrating  Quality  Function  Deployment  into  the 
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Concurrent  Engineering  Environment.  The  proposed  approach  was  to  use  a  technique  called 
Quality  Function  Deployment  (QFD)  as  the  framework  for  the  system  architecture. 

QFD  was  originaily  proposed  as  the  methodological  framework  in  our  Phase  I  proposal  because  it 
represented  a  comprehensive  system  that  translates  customer  expectations  on  functional 
requirements  into  specific  engineering  and  quality  characteristics.  Given  the  CE  origins  of  the 
solicitation,  it  was  logical  to  consider  that  a  QFD  system  for  designing  products  based  on 
customer  requirements,  involving  all  members  of  the  design,  development,  and  support 
communities,  would  provide  an  effective  foundation  for  our  efforts.  At  that  time,  CE  was  defined 
as  an  integrated  process  that  engineers  the  product,  the  manufacturing,  and  its  support  processes 
together  with  emphasis  on  efficiency,  improved  quality,  and  reduced  cost. 

A  Phase  I  contract  was  awarded  to  QDM  effective  23  April  1991.  Since  this  initial  award,  much 
has  changed.  The  technologies  and  ideologies  relevant  to  the  effort  have  steadily  matured.  The 
essence  of  QFD  and  CE  was  the  process  of  integrated  design,  engineering,  and  manufacturing. 
Yet  the  emphasis  of  our  S6IR  effort  is  on  the  systems  and  processes  that  support  the  people 
working  in  the  framework  of  a  CE  process.  Consequently,  the  emphasis  of  our  research  and 
development  shifted  from  the  specifics  of  CE  to  incorporate  the  aspects  of  Total  Quality 
Management  (TQM),  continuous  improvement,  and  learning  organizations  which  address  the 
behaviors  of  people  in  the  process,  not  the  mechanics  of  the  process  itself 

QDM,  in  addition  to  keeping  pace  with  such  methodological  advances,  has  had  to  continue  to 
manage  the  relationship  with  our  Air  Force  customer  during  the  time  of  wholesale  changes  in  the 
framework  of  that  organization  throughout  both  phases  of  the  effort.  QDM  has  had  the  challenge 
of  developing  and  delivering  a  system  that  not  only  makes  use  of  the  best  currently  available  tools 
and  techniques  but  also  meets  the  specific,  changing  requirements  of  the  Air  Force. 

Although  the  Armstrong  Laboratories  Logistics  Research  Branch  originally  submitted  the 
research  topic  and  serves  as  the  contract  monitor,  an  organization  called  the  FACTS  office  has 
defined  many  of  the  technical  requirements  and  financed  the  Phase  I  and  Phase  II  efforts 
completely.  The  Fasteners,  Actuators,  Connectors,  Tools,  and  Subsystems  (FACTS)  office  is  the 
organization  that  has  undergone  extensive,  iterative  reorganizations  throughout  this  effort. 

The  foundation  for  the  FACTS  office  was  laid  in  June  1988,  when  the  Air  Force  chartered  a 
Scientific  Advisory  Board  (SAB)  panel  to  investigate  Aircraft  Infrastructure-Subsystem  and 
Component  Reliability  Research  and  Development  Needs.  Because  of  significant  improvements 
made  in  the  preceding  decades  to  aircraft  electronics,  engines,  structures,  materials,  and  software, 
the  seemingly  simple  subsystems  in  the  mechanical  infrastructure  had  become  limiting  factors  to 
continued  improvements  in  overall  weapon  system  reliability  and  maintainability. 

The  SAB  panel  concluded  that  the  Air  Force  spends  approximately  $2  billion  annually  on  simple 
structural  aircraft  parts  (screws,  nuts,  bolts,  etc  ).  Responsibility  and  management  of  these  parts 
had  been  spread  throughout  the  federal  government,  including  the  Defense  Logistics  Agency 
(DLA),  the  General  Services  Administration  (GSA),  and  the  DoD.  In  January  1990,  the  FACTS 
office  was  established  to  address  the  SAB  findings.  FACTS  is  charged  with  improving  the 
reliability  and  maintainability  of  FACTS  parts  and  with  improving  the  processes  in  place  to 
acquire  and  provide  the  parts  to  aircraft  maintainers. 
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The  original  Phase  I  effort  concluded  on  23  October  1991.  During  this  phase  of  research.  QDM 
demonstrated  the  feasibility  of  the  proposed  environment  through  research  and  demonstration  of 
stand-alone  pieces  of  existing  and  emerging  technology  in  the  areas  of  groupware,  business 
process  redesign,  workflow  management,  management  and  planning  tools,  and  graphical  user 
interface  environments.  Results  included. 

*  design  of  a  methodology  that  thoroughly  supports  cross-functional  teamwork  and 
collaboration; 

*  design  of  a  system  that  can  be  developed  with  minimal  risk  through  the  integration  of 
proven,  existing  technology; 

*  establishment  of  technology  partner  relationships  with  commercial  software  co  ^  anies 
possessing  related  existing  and  emerging  technology,  and  with  early  end-user  adopters; 

*  demonstration  and  prototype  development  in  groupware  and  open  workgroup  computing 
environment  applications  using  Lotus  Notes;  and 

*  demonstration  of  the  feasibility  of  a  graphical  database  program  to  link,  organize,  and 
display  data  from  different  databases. 

To  maintain  continuity  in  the  research  effort  between  Phase  I  and  Phase  II,  a  four  month 
modification  to  the  Phase  I  effort  was  made  effective  3  February  1992.  The  modification 
consisted  of  three  tasks  extracted  from  the  initial  tasks  proposed  for  the  Phase  II  effort,  but  the 
major  focus  of  the  Phase  I  modification  effort  was  research  in  workflow  methodology  and 
technology  to  create  a  prototype  workflow  management  system  in  a  groupware  environment.  We 
were  very  successful  in  that  regard,  as  a  workflow-enabled  Project  application  was  installed  and 
used  by  the  Business  Opportunities  Division  of  the  Center  of  Supportability  and  Technology 
Insertion  (CSTI).  (At  the  time  the  initial  workflow  application  was  developed,  the  FACTS  office 
was  a  part  of  the  CSTI  organization.)  Detailed  information  about  this  system  is  given  in  the 
Workflow  Module  section  of  this  report.  Phase  I  Modification:  PI  BO  Production  Workflow 
System. 


Outline  of  Final  Phase  II  Report 

This  report  summarizes  more  than  three  years  of  a  truly  innovative  research  and  development 
effort  which  has  resulted  in  cutting-edge  technology  and  valuable,  practical  knowledge.  In 
addition  to  this  introductory  section,  the  report  contains  the  following  sections. 

Groupware  System  for  Multidisciplinary  Participation  describes  the  assumptions,  method,  and 
approach  used  throughout  the  research  effort.  Emphasis  on  the  important  consideration  of 
cultural  phenomena  in  the  design  of  the  software  system  is  explained.  The  section  chronicles  the 
evolutionary  development  of  the  groupware  system,  procedures  for  the  iterative  development 
process,  and  the  application  of  the  technology  to  a  selected  test  environment. 
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Discussion  of  Results  presents  the  results  of  the  research  effort.  Results  are  reported  with  respect 
to  the  relative  successes  of  the  portions  of  technology  development  as  well  as  results  from  the  use 
and  implementation  of  the  technology  in  the  test  environment. 

Comluding  Remarks  discusses  the  outcome  of  the  results  with  respect  to  our  initial  assumptions 
and  the  implications  of  these  results  for  the  future.  The  section  enumerates  observations  made  by 
the  research  team  and  explains  how  these  observations  can  be  leveraged  to  produce  the  most 
benefit  fi-om  the  effort. 

Recommendations  concludes  the  report  with  a  series  of  suggested  actions  specific  to  the  test 
environment  and  also  to  technical  and  management  communities  in  general.  This  section 
describes  our  strong  beliefs  about  where  the  groupware  market  is  heading  and  what  approaches 
will  be  necessary  to  derive  the  most  benefit  from  a  powerful  new  discipline. 

GROUPWARE  SYSTEM  FOR  MULTIDISCIPLINARY 

PARTICIPATION 

The  Role  of  Management  Technology 

Basis  of  Quality  Decision  Management’s  Methodology 

Since  the  origins  of  this  effort  began  four  years  ago,  we  have  witnessed  substantial  changes  in  the 
research  and  theories  which  have  influenced  the  outcome  of  this  SBIR  effort.  From  an  initial 
emphasis  on  CE,  the  process  of  integrated  design,  engineering,  and  manufacturing,  the  emphasis 
of  our  SBIR  effort  has  focused  on  the  systems  and  processes  that  support  the  people  working  in 
the  firework  of  a  CE  process. 

In  fact,  the  emphasis  of  our  SBIR  effort  is  on  the  systems  and  processes  that  support  people 
working  together  toward  the  achievement  of  any  business  objective.  It  became  increasingly 
apparent  throughout  this  research  effort  that  certain  fundamental  activities  are  common  to  any 
organization  or  group  of  people  working  together,  regardless  of  the  nature  of  the  work.  QDM’s 
methodology  is  based  on  the  fundamental  elements  of  how  people  work  together  and  what  tools 
and  techniques  can  facilitate  coordinated  group  activity. 

Consequently,  the  emphasis  of  our  research  and  development  shifted  from  the  specifics  of  CE  to 
incorporate  the  aspects  of  TQM,  continuous  improvement,  and  learning  organizations  that 
address  the  behaviors  of  people  in  the  process,  not  the  mechanics  of  the  process  itself 
Coordinating  requests  and  actions,  soliciting  input  fi'om  colleagues  to  make  effective  decisions, 
building  consensus  Avithin  the  group,  learning  from  group  experiences  and  best  practices, 
experimenting  with  new  approaches,  all  represent  skills  fundamental  to  workgroup  activity. 

The  Air  Force  demonstrated  its  awareness  of  this  shift  during  the  course  of  our  effort  in  the 
evolution  of  CE  into  Integrated  Product  Development  (IPD).  IPD  incorporates  the  principles  of 
TQM  to  emphasize  the  importance  of  teamwork  and  continuous  process  improvement  in  the 
design  and  acquisition  of  systems.  QDM  continued  to  build  on  this  trend  throughout  the  effort. 
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As  the  theories  involved  in  CE  evolved  into  IPD  and  our  original  emphasis  on  QFD  expanded  to 
encompass  TQM,  continuous  improvement,  and  organizational  learning,  QDM  devised  a  set  of 
procedures  and  techniques  that  integrate  aspects  of  all  these  methodologies  to  help  businesses 
meet  and  exceed  customer  requirements.  Through  organization-wide  continuous  improvement, 
businesses  are  able  to  consistently  satisfy  customers  and  reach  corporate  goals. 

Noted  researchers  and  respected  analysts  such  as  Dr  Robert  Johansen  of  the  Institute  for  the 
Future  (IFTF),  David  and  Ronni  Marshak  of  the  Patricia  Seybold  Group,  Esther  Dyson  of 
ED  Venture  Holdings,  and  fellow  pioneers  in  groupware  development  such  as  Action 
Technologies  and  Lotus  Development  Corporation  have  praised  QDM’s  proposed  methodology 
as  iimovative  and  highly  applicable.  These  people  and  companies  are  pleased  by  QDM’s  emphasis 
on  groupware  technology  as  a  means  to  support  processes  rather  than  as  a  means  of  passing  data 
across  networks. 

As  defined  in  our  methodology,  three  factors  create  and  sustain  an  environment  of  teamwork  to 
deliver  customer  satisfaction.  The  three  factors,  as  depicted  in  Figure  4,  are: 

*  horizontal  communication, 

*  daily  management,  and 

*  vertical  alignment. 


Figure  4 

Methodology  to  Support  Multidisciplinary  Participation 
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Horizontal  communication  concerns  the  methods  by  which  the  functions  and  departments 
throughout  an  organization  work  together  to  achieve  the  mission.  To  effectively  accomplish  the 
organization’s  mission,  cooperation  across  many  different  functions  and  disciplines  is  required. 
The  emphasis  is  on  effective  collaboration,  not  simply  on  communication.  Horizontal 
communication  requires  collectively  sharing  ideas  and  information. 

Another  important  factor  for  a  complete  team  environment  is  daily  management.  Daily 
management  is  characterized  by  the  actions  that  cascade  through  an  organization  to  incrementally 
achieve  organizational  objectives.  Without  a  way  to  manage  the  endless  variety  of  fundamental 
tasks  that  collectively  bring  an  organization  closer  to  long  range  objectives,  meamngful  progress 
toward  objectives  would  be  impossible.  Typically,  we  refer  to  these  fundamental  tasks  as  work, 
and  we  refer  to  the  process  of  performing  these  tasks  as  workflow. 

Vertical  alignment  refers  to  processes.  How  does  an  organization  plan  strategic  objectives  and 
determine  its  direction?  How  does  an  organization  create  awareness  of  processes  and  draw  upon 
the  expertise  of  everyone  from  the  CEO  to  the  assembly  line  worker  to  follow  strategic  direction? 
To  answer  these  questions  is  to  define  processes  that  represent  the  organization  and  provide 
information  about  how  the  organization  thinks  and  works  together.  A  process-orientation 
provides  meaningful  perspective  for  all  people  in  the  organization  regarding  their  roles  in  the 
process  and  their  contribution  to  organizational  objectives.  Vertical  alignment  can  be  achieved 
through  modeling  organizational  processes. 

Horizontal  communication,  daily  management,  and  vertical  alignment  are  the  components  of  our 
system  for  multidisciplinary  participation.  Even  independent  of  software,  an  environment  that 
sustains  effective  teamwork  will  consist  of  a  synergistic  blend  of  these  components.  The 
groupware  system  designed  during  Phase  II  of  our  SBIR  effort  aims  to  achieve  this  synergy  and 
to  dramatically  improve  the  effectiveness  of  these  elements  both  as  individual  components  and  as 
a  complete,  integrated  system. 

Mapping  Technology  to  the  Methodology 

The  factors  of  horizontal  communication,  daily  management,  and  vertical  alignment  can  each  be 
addressed  by  pieces  of  existing  technology.  QDM’s  goal  for  the  Phase  II  SBIR  effort  was  to  not 
only  address  each  factor  separately,  but  to  use  these  software  technologies  to  craft  an  integrated 
management  system. 

The  Groupware  platform  itself  is  instrumental  in  addressing  the  horizontal  conununication  aspect 
of  the  methodology.  Indeed,  the  whole  idea  behind  Groupware  is  enabling  exactly  the  type  of 
information-sharing  that  is  called  for  in  our  methodology  to  support  multidisciplinary 
participation.  Groupware  platforms  such  as  Lotus  Notes*  help  users  from  all  departments  and 
disciplines  contribute  their  own  expertise  and  profit  from  that  of  others.  All  users  have  the  full 
complement  of  information  with  which  to  collaborate  effectively  and  to  make  informed  decisions. 

A  workflow  system  can  be  the  technological  vehicle  used  by  team  members  to  act  on  these 
decisions.  While  workflow  can  take  the  form  of  blind,  station-to-station  routing  of  responsibility, 
QDM  believes  that  a  workflow  system  can  and  should  have  a  methodological  foundation. 
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Because  a  workflow  system  can  facilitate  the  most  fundamental  aspect  of  a  business’  operations, 
the  daily  management  of  assignments  and  activities,  it  must  be  grounded  in  a  solid,  proven 
philosophy.  The  value  that  QDM  placed  on  the  methodological  aspects  of  workflow,  especially 
as  they  relate  to  the  daily  management  of  activity,  led  us  to  select  the  Action  Technologies,  Inc. 
tools  and  methods  detailed  in  the  Worl0ow  Module  section. 

A  process  orientation  allows  a  business  to  examine  the  activities  that  are  taking  place  via  the 
workflow  system.  Examining,  analyzing,  and  modifying  processes  is  critical  to  the  notion  of 
vertical  alignment.  QDM’s  plan  for  the  Phase  n  SBIR  effort  was  to  build  a  Graphical  User 
Interface  (GUI)  over  the  workflow  module  of  the  system.  This  tool  would  read  data  from  the 
workflow  module,  then  graphically  display  process-oriented  information  in  colorful,  dynamic, 
easy-to-understand  charts  and  graphs.  These  displays  can  be  viewed  by  all  appropriate  levels  of 
the  company  to  increase  process  awareness  and  analysis.  A  well-designed  Graphical  User 
Interface  gives  everyone  a  better  understanding  of  organizational  processes  and  each  individual’s 
specific  role  in  them. 

Quality  Decision  Management’s  Critical  Assertion:  The  Human  Side  of 
Management  Technology 

All  of  the  technologies  discussed  above  are  readily  available.  The  market  for  Groupware  and 
workflow  systems  is  exploding.  GUI  technology  has  existed  for  more  than  a  decade  and  gets 
smarter  and  more  powerful  with  each  successive  release.  Each  of  these  technologies  is 
sufficiently  sophisticated  to  perform  the  functions  and  provide  the  benefits  described  above.  As 
these  technologies  continue  to  undergo  refinement  and  widespread  proliferation,  it  becomes  more 
and  more  clear  that  the  barrier  to  organization-wide  change  and  continual  process  improvement  is 
not  technological. 

In  fact,  not  only  are  these  technologies  not  barriers  to  change,  they  actively  enable  it: 

“Groupware  and  organizational  change  go  best  hand  in  hand”  (Opper,  1992).  What,  then,  is 
preventing  organizations  and  businesses  around  the  world  from  immediately  realizing  the  benefits 
of  groupware?  The  answer  to  this  question  is  the  core  of  QDM’s  philosophy:  Technology 
Cannot  Drive  the  Organization.  Note  that  in  our  discussion  above,  we  mapped  the  technology  to 
our  existing  methodology,  not  the  reverse.  The  agents  for  change  and  improvement  thus  remain 
conceptual,  not  technological.  It  is  better  to  model  a  business  after  solid  concepts  of 
management,  communication,  and  alignment  than  to  force  the  model  into  a  preexisting 
technological  mold. 

Simply  stated,  QDM’s  core  philosophy  is  that  having  individuals  and  workgroups  perform 
processes  as  dictated  by  the  parameters  and  constraints  of  their  hardware  and  software  technology 
is  putting  the  cart  before  the  horse.  Rather,  the  technology  must  be  responsive  to  the 
organization  and  sensitive  to  the  corporate  culture.  User  needs  should  drive  the  design  of  the 
information  architecture. 

However,  even  a  culturally  sensitive  system  is  prone  to  failure  if  it  meets  with  consistent, 
unbending  user  resistance.  In  using  technology  to  effect  change  and  move  toward  a  “Learning 
Organization,”  everyone,  from  management  through  support  staff,  must  commit  to  the  effort  and 
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accept  the  system  as  an  effective  change  agent.  All  users  must  be  eager  (or  at  least  willing)  to  use 
the  technology  to  acquire  knowledge  about  the  way  they  do  things.  They  should  be  ready  to  use 
this  knowledge  to  continually  reexamine,  reevaluate,  and,  if  necessary,  modify  their  behavior  to 
optimize  performance. 

Avoiding  this  resistance  in  the  first  place  is  much  easier  than  overcoming  it.  Thus,  QDM’s  core 
assertion  about  the  creation  of  technology  solutions  also  applies  to  their  implementation.  The 
introduction  of  new  technologies  into  the  user  environment  should  be  as  culturally  seamless  as  the 
technologies  themselves,  gradually  building  user  acceptance  from  the  foundation  of  an  initially 
positive  reaction. 


Rapid  Prototype  Development  Process 

QDM’s  approach  to  software  development  mimics  that  of  a  successful  user  of  a  well-designed 
groupware  system.  Such  users  take  an  iterative  approach  to  continuous  improvement.  They  use 
the  system  to  capture  and  analyze  their  work  patterns,  repeat  those  that  proved  successful,  and 
modify  those  that  could  be  improved.  QDM’s  Rapid  Prototype  Development  Process  was 
similarly  iterative;  we  would  incrementally  develop  prototypes  of  systems  and  continually  modify 
them  based  on  feedback  fi-om  Air  Force  users.  We  would  add  desired  functionality  and  tailor  the 
system  to  ensure  the  system  continued  to  meet  the  changing  needs  of  our  customer. 

One  of  the  most  important  factors  in  QDM’s  ability  to  develop  prototype  systems  rapidly  was  our 
ability  to  leverage  and  integrate  proven,  existing  technologies  rather  than  attempting  to  build 
everything  firom  scratch.  The  Groupware  platform,  workflow  capabilities,  and  Process-Oriented 
Graphical  Front  End  were  selected  to  address  the  collaboration,  coordination,  and  process 
awareness  aspects  that  are  the  cornerstones  of  QDM’s  methodology  (see  Figure  5). 


13 


Incremental  Development  Approach 


Figure  5 

With  the  Groupware  platform  as  a  baseline,  functionality  consistent 
with  QDM’s  developed  methodology  is  added  to  form  a 
fully  integrated  system 

As  explained  above,  each  of  these  individual  modules  of  technology  is  mapped  to  a  critical  factor 
of  our  teamwork  environment  methodology:  the  collaboration  of  Groupware  to  the  horizontal 
communication  factor,  workflow  methodology  to  the  management  of  daily  activity,  and 
GUI-enabled  process  awareness  to  vertical  alignment.  The  management  tools  are  fully  integrated 
with  the  other  modules  and  address  all  three  of  the  teamwork  factors,  as  shown  in  Figure  6. 
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Figure  6 

Each  module  of  SBIR  technology  development  is  mapped  to  a 
teamwork  factor  in  QDM’s  methodology 

Again,  the  goal  of  the  system  is  not  only  to  take  advantage  of  each  individual  component,  but  also 
to  allow  businesses  to  profit  fi^om  the  synergy  of  the  technologies  and  theories.  Each  component 
benefits  from  the  others.  For  example,  the  processes  being  automated  by  the  workflow  module 
are  also  being  analyzed,  discussed,  and  honed  with  the  help  of  the  process  awareness  created  by 
the  GUI  and  the  improved  communication  and  collaboration  made  possible  by  the  groupware 
platform.  These  interconnected  modules  form  a  powerful,  responsive  system  that  helps  businesses 
achieve  their  goals  by  facilitating  effective  teamwork  in  a  “different  time/different  place” 
paradigm. 

The  Groupware  Platform 

Perhaps  the  most  critical  design  decision  in  the  entire  SBIR  effort  was  selecting  the  platform  on 
which  to  build  the  system.  The  ability  of  the  other  modules  of  the  system  to  work  effectively 
together  would  depend  largely  on  the  flexibility  and  robustness  of  the  Groupware  foundation. 

QDM  chose  Lotus  Notes*  a  product  still  in  its  infancy  at  the  time,  as  the  baseline  to  which  all 
other  functionality  would  be  added.  QDM  recognized  Lotus  Notes’  power  as  a  group 
conununications  forum.  Such  features  as  Client/Server  Architecture  and  Database  Replication 
make  this  platform  a  solid  foundation  from  which  to  build  complex,  integrated,  group-oriented 
software  systems. 
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At  the  time  QDM  selected  Lotus  Notes  as  the  groupware  platform,  effectively  no  competitive 
product  was  on  the  market,  as  is  still  the  case  four  years  later.  Several  unique  features  made 
Lotus  Notes  an  intelligent  choice. 

♦  The  ability  to  operate  in  a  mixed  networking  environment  (e  g.  Novell,  LAN-MAN, 

Banyan  VINES,  etc.)  and  a  variety  of  hardware  platforms  and  operating  systems  (e  g. 
IBM/PC,  Macintosh,  and  Unix).  Such  mixed  environments  are  common,  especially  in  large 
organizations. 

♦  The  power  and  versatility  of  Lotus  Notes  documents.  They  can  capture,  store  and  route 
everything  from  simple  text  to  spreadsheets,  graphics,  scanned  images,  and  even 
full-motion  video.  This  power  is  consistent  with  (indeed,  at  the  forefront  of)  current 
multimedia  trends. 

♦  The  organizational  capabilities  of  Lotus  Notes  views.  Lotus  Notes  views  are  relatively 
easy  to  build  and  are  powerful  ways  to  categorize  and  work  with  Lotus  Notes  documents. 

♦  The  embodiment  of  the  many-to-many  paradigm.  Information  is  stored  in  a  common 
repository  (database),  so  entire  groups  can  work  together  with  these  documents  and  views 

Lotus  Notes  embodies  two  important  characteristics,  which  made  it  an  ideal  choice  for  our  effort. 
First,  Lotus  Notes  is  simply  an  operating  system  and  development  platform  for  group 
applications.  Much  like  DOS,  Windows,  OS/2,  or  any  operating  system  required  to  program  and 
subsequently  operate  a  spreadsheet  or  word  processing  application,  Lotus  Notes  is  an 
environment  that  allov/s  one  to  program  and  operate  workgroup  applications  such  as  a  client 
tracking  system.  Help  Desk,  or  group-oriented  project  management  application. 

Secondly,  Lotus  Notes  is  a  platform  that  provides  both  private  and  public  workspace.  Using  the 
electronic  mail  component  of  Lotus  Notes,  you  may  send  messages  directly  to  other  individuals 
“one-to-one.”  Yet  if  users  choose,  they  may  also  enter  and  access  information  in  applications  that 
are  publicly  shared  by  many  other  users.  Like  a  public  file  cabinet,  information  is  stored  and 
available  if  and  when  you  need  to  access  it.  The  unique  replication  capability  of  Lotus  Notes 
allows  access  to  the  information  from  any  place  at  any  time. 

The  Workflow  Module 

As  explained,  the  selection  of  a  baseline  workflow  technology  was  neither  a  trivial  nor  a  purely 
technological  decision.  Many  technologies  that  enabled  the  station-to-station  routing  of  forms, 
documents,  or  responsibilities  were  available,  but  QDM  believes  workflow  can  and  should  be 
much  more  than  automation  of  the  paper  trail.  We  sought  a  system  that  had  some  theory  behind 
it,  a  system  that  is  not  based  on  the  routine  shuffling  of  paper  but  on  the  ways  in  which  people 
really  work  together  to  get  the  job  done. 

The  workflow  technology,  like  everything  else  that  QDM  integrated  into  the  Groupware  System 
for  Multidisciplinary  Participation,  had  to  have  a  methodological  link  to  management  science.  If 
some  theory  is  embedded  in  the  technology,  the  technology  can  act  as  an  agent  for  improvement. 
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Daily  use  of  the  system  will  instill  and  consistently  reinforce  the  effective  practices  that  are  built 
into  the  software. 

The  Basic  Action  Workflow  from  Action  Technologies,  Inc.  (ATI)  is  the  best  example  of  a 
production  workflow  system  that  embodies  a  philosophy  of  how  people  work  together.  The  ATI 
paradigm  reduces  all  business  processes  to  a  linked  series  of  “conversations”  between  a  person 
who  asks  that  a  job  get  done  (the  customer  in  the  process)  and  the  person  responsible  for 
performing  it  (the  performer  of  the  process).  Each  conversation  is  a  miniature  “closed-loop 
feedback”  system  which  is  fully  complete  only  when  the  customer  declares  that  the  work  has  been 
performed  satisfactorily. 

During  our  Phase  I  effort,  QDM  conducted  extensive  research  in  ATI’s  technology.  We  worked 
closely  with  ATI  as  a  technology  partner  for  early  versions  of  the  Workflow  Management  Server 
(WMS)  en^ne,  helping  to  define  required  capability  for  the  product  based  on  our  intended  uses. 
QDM  worked  together  with  ATI  and  Lotus  Development  Corporation  to  test  this  philosophy  and 
technology  in  some  of  the  earliest  Lotus  Notes/ ATI  workflow  pilot  programs.  Both  the  theory 
and  the  technology  that  houses  it  have  continually  proven  effective  in  describing  and  automating 
complex  business  processes  for  customers  across  a  wide  range  of  industries.  Indeed,  the 
philosophy  and  the  method  for  embedding  it  into  software  have  proven  sufficiently  relevant  and 
innovative  to  warrant  the  awarding  of  two  United  States  patents  to  the  principal  inventors  at  ATI. 

Enabling  Business  Prccesses  with  the  Basic  Action  Workflow 

The  workflow  module  that  was  built  for  Phase  II  of  QDM’s  SBIR  effort  embodies  the  ATI 
methodology  (fully  described  below).  Some  of  the  material  that  follows  was  extracted  from  ATI's 
Actionworl^OH^  Application  Development  Guide. 

The  Basic  Action  Workflow,  shown  in  Figure  7,  is  a  unit  of  coordination  between  two  parties;  the 
customer  and  the  performer.  The  workflow  occurs  in  four  phases,  and  is  begun  by  a  request  or  an 
offer. 
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Figure  7 

Basic  Action  Workflow  as  dermed  by  Action  Technologies,  Inc. 
and  embodied  in  the  QOM  SBIR  Phase  II  Workflow  Module 

The  customer  asks  the  performer  to  fulfill  some  action.  TWs  request  occurs  during  the  “initial” 
phase  of  the  workflow.  In  the  next  phase,  “negotiation,”  the  performer  can  agree,  decline  or 
counteroffer  the  request.  If  agreement  is  reached,  the  performer  fulfills  the  request  and  d-clares 
fulfillment  in  the  “in  progress”  phase.  Finally,  the  customer  declares  satisfaction  or  dissatisfaction 
with  the  work  of  the  performer  in  the  “completing”  phase. 

This  structure  is  designed  to  be  a  reflection  of  what  people  do  while  coordinating  action  with  each 
other  every  day.  By  making  the  terms  of  the  agreement  explicit  with  acts  of  coordination,  it  is 
now  possible  to  observe  coordinations  better  and  to  design  tools  and  applications  to  support 
coordinating  our  actions  better. 

The  basic  action  workflow  is  made  up  of  twelve  workflow  acts.  If  no  exceptions  exist  in  the 
workflow,  the  four  acts  of  request,  agree,  declare  fulfillment,  and  declare  satisfaction  will  move 
the  transaction  fi-om  beginning  to  completion  with  a  satisfied  customer.  This  progression  is 
referred  to  as  the  “no-exception”  path  of  the  workflow.  The  fifth  act,  declaring  dissatisfaction  by 
the  customer,  is  a  response  to  the  performer  declaring  completion.  This  dissatisfaction  puts  the 
process  back  into  the  “in  progress”  phase  until  the  customer  is  satisfied. 

The  state  of  a  workflow  is  one  of  eight  states  that  precede  or  follow  workflow  acts.  Counteroffer 
and  the  four  acts  of  negotiation  are  included  in  the  state  “In  Negotiation.”  Figure  8  provides  the 
state  codes  used  in  the  Lotus  Notes  implementation  of  Workflow  Management.  These  codes  will 
be  used  in  formulas  to  drive  logic  in  the  Lotus  Notes  applications.  The  workflow  state  before  and 
after  acts  and  the  letter  codes  for  each  are  also  illustrated  in  Figure  8. 
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Workflow  State  Before  and  After  Acts 

Other  situations  often  occur,  in  addition  to  agreement  when  a  request  is  made.  Instead  of 
agreeing  to  a  request,  the  performer  can  make  a  counteroffer.  If  asked  to  “deliver  the  report  you 
are  working  on  tonight”,  a  counteroffer  might  be,  “it  won’t  be  completed  until  tomorrow  night, 
but  I  can  give  you  most  of  it  tonight.”  A  performer  can  decline  to  agree  to  what  the  customer 
asks,  but  offer  some  other  conditions  of  satisfaction  that  might  satisfy  the  customer. 

In  the  Action  Workflow,  four  acts  have  to  do  with  negotiation,  the  interchange  between  a 
customer  and  performer  that  is  started  by  a  counteroffer.  During  negotiation  the  performer  and 
customer  offer  different  conditions  of  satisfaction  until  they  reach  agreement  or  terminate  the 
negotiation.  The  acts  that  make  up  negotiation  in  the  Action  Workflow  are  illustrated  in  Figure  9. 
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When  the  performer  makes  a  counteroffer  to  a  request,  the  customer  can  make  one  of  three 
state-change  responses:  agree  with  the  counteroffer,  insist  on  the  conditions  of  satisfaction  of  the 
original  request,  or  make  another  counteroffer.  The  customer  making  a  counter  response  to  a 
counteroffer  is  called  a  “counter- with  request.”  The  customer  and  performer  can  go  on 
countering  each  other  without  limit.  In  actual  negotiations  the  interaction  eventually  leads  to  an 
agreement  or  to  termination. 

The  four  workflow  acts  for  negotiation  after  a  request  are: 

♦  counteroffer  by  performer, 

♦  accept  counteroffer  by  customer, 

♦  insist  (which  is  a  decline  counteroffer)  by  customer,  or 

♦  counter  (with  a  request)  by  customer. 

When  the  customer  counters  a  counteroffer,  the  performer  is  given  the  same  options  as  for  the 
initial  request:  agree,  decline,  or  counteroffer. 

A  workflow  can  either  complete  with  the  customer  declaring  satisfaction  or  termination.  Both  the 
customer  and  the  performer  in  a  workflow  can  terminate  it.  The  three  acts  that  terminate  the 
workflow  are:  decline,  cancel,  and  revoke. 

The  acts  that  can  cause  termination  are  illustrated  below.  These  acts  can  be  taken  in  the  phases 
shown  in  Figure  10. 
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Figure  10 

Termination  Acts  of  a  Workflow 

Decline:  When  a  customer  requests  an  action  from  a  performer,  one  response  the  performer  can 
make  is  to  decline.  In  declining,  the  performer  is  promising  not  to  do  what  is  asked  and  is 
terminating  the  workflow. 

Decline  is  an  appropriate  act  only  in  the  negotiation,  after  a  request  and  before  an  agreement. 
After  an  agreement,  if  the  performer  wishes  to  withdraw  from  the  agreement,  agreement  is 
revoked. 

Revoke:  After  an  agreement,  the  performer  can  terminate  a  workflow  by  taking  this  action. 
Revoke  can  only  happen  between  the  agreement  and  the  declaration  of  fulflllment,  as  is  illustrated 
in  Figure  10.  A  performer  cannot  revoke  an  agreement  if  it  has  already  been  fulfilled. 

Cancel:  Cancel  is  an  act  taken  by  the  customer,  canceling  the  request.  A  customer  can  cancel 
the  request  any  time  after  the  request  is  made,  but  before  satisfaction  has  been  declared.  Thus, 
Cancel  is  an  act  available  to  the  customer  at  any  time  in  the  three  phases  of  Negotiation,  In 
Progress,  and  Completing. 

Phase  I  Modification  —  Process  Improvement  Business  Opportunities  Office 
(PIBO)  Production  Workflow  System 

In  early  1991,  during  Phase  I  of  this  SBIR  effort,  QDM  acquired  the  suite  of  software 
components  licensed  from  ATI  and  worked  closely  with  the  ATI  development  team  to  understand 
the  methodology  described  above  and  the  technology  that  embodied  it.  Upon  gaining  this 
understanding,  we  then  proceeded  to  the  Phase  I  Modification  of  the  effort,  which  began  vdth  the 
development  and  implementation  of  a  production  workflow  system.  Our  observations  of  the 
results  of  this  system,  in  combination  with  the  feedback  we  would  receive  from  the  Process 
Improvement  Business  Opportunities  Office  (PIBO),  would  ultimately  prove  instrumental  in  the 
design  and  implementation  of  the  Phase  II  Workflow  Module. 
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We  identified  the  Process  Improvement  Business  Opportunities  Office  of  the  Center  for  Support 
of  Technology  Insertion  (CSTI/PIBO)  as  the  test  bed  for  a  pilot  workflow  management 
application.  At  the  time,  the  CSTI/Process  Improvement  (PI)  organization  included,  in  addition 
to  the  FACTS  office,  the  Productivity,  Reliability,  Availability,  and  Maintainability  Program 
(PRAM)  and  the  Reliability  and  Maintainability  Technology  Insertion  Program  (RAMTIP).  PIBO 
determined  what  projects  the  organization  would  accept  and  which  branch  of  the  organization 
should  manage  the  project.  The  application  was  to  be  a  workflow-enabled  version  of  the  PIBO 
Project  Tracker  application  (a  Lotus  Notes-based  application  that  QDM  had  developed  for  PIBO 
under  a  separate  contract).  The  Project  Tracker  application  managed  the  flow  of  projects  through 
a  series  of  states  and  databases,  from  proposed  to  accepted  to  completed/closed.  The  project 
would  move  to  the  appropriate  location  in  the  system  when  its  state  changed. 

The  workflow-enabled  Project  Tracker  would  be  more  valuable  because  it  would  coordinate  not 
only  the  movement  of  project  forms  based  on  their  changing  states  but  would  also  automate  the 
actions  of  team  members  that  were  necessary  for  the  project  to  change  states.  While  the  Project 
Tracker  automated  the  management  of  project  documents,  the  workflow-enabled  Project  Tracker 
automated  the  activities  of  people.  The  Workflow  management  component  would  allow  the 
Lotus  Notes  groupware  platform  to  alert  performers  about  pending  actions  and  assignments  to 
teams  and  allow  customers  and  managers  to  view  the  current  state  of  a  project  and  see  whose 
next  action  is  pending. 

Before  the  prototype  application  could  be  developed,  the  PIBO  business  process  had  to  be 
defined  and  analyzed  to  determine  exactly  the  flow  of  work  and  responsibility  around  the  process. 
A  team  consisting  of  QDM  management  consultants,  a  senior  programmer,  and  a  business  process 
analyst  from  ATI  interviewed  several  members  of  the  PI  community.  The  product  of  the 
interviews  was  a  business  process  map  depicting  the  PIBO  process.  (See  Figure  1 1). 

Using  this  map  as  the  specification  for  how  the  PIBO  process  operates,  an  application  that 
initiates  the  specific  tasks  in  the  listed  sequence  was  designed.  This  map  depicts  a  series  of 
ATI-style  “closed-loop  feedback  conversations”  that  govern  the  project  review  process.  The 
process  begins  with  a  determination  of  a  given  project’s  relevance  to  the  PI  office  by  the  PI  Chief 
Based  on  this  determination,  the  project  is  then  planned  and  launched;  a  team  leader  and  team 
members  are  assigned,  the  project  is  further  investigated  and  briefed,  and  a  project  plan  is  drafted, 
reviewed,  and  revised. 
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Figure  11 

Business  Process  Map  depicting  the  process  in  the  PI  Business 
Opportunities  office  as  a  series  of  interrelated  workflows 

After  an  iiutial  review,  several  changes  and  enhancements  were  made  to  the  workflow 
management  Project  Tracker  system.  In  fact,  the  process  was  entirely  re-mapped  and  redesigned 
several  times  because  of  changes  in  both  in  the  process  itself  and  in  the  organization  that 
performed  it.  Organizational  realignments  within  the  Air  Force  brought  about  new  and  redefined 
steps  in  the  process,  all  of  which  had  to  be  accounted  for  by  the  system.  Only  after  much 
realignment  and  juggling  was  the  process  sufficiently  “frozen”  to  be  automated  by  production 
workflow. 

The  resulting  system,  including  a  version  of  the  WMS  Engine  licensed  to  QDM  by  ATI  for 
purposes  of  prototype  application  of  the  technology,  was  installed  for  PI  after  finally  settling  on  a 
design  for  the  process.  Representatives  from  PIBO  were  trained  to  use  the  workflow 
management  application.  Training  focused  on  describing  the  steps  of  the  PIBO  process;  from  an 
end-user  perspective,  the  system  is  simply  a  Lotus  Notes  application.  A  Notes-based  application 
was  established  to  collect  and  record  user  comments  and  feedback  during  the  test  phase.  This 
feedback  would  be  put  to  use  in  the  development  and  production  of  the  workflow  system  as  the 
project  extended  into  the  Phase  11  effort. 
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integrating  Ad-Hoc  Workflow  Toois  into  the  Production  Workflow  Environment  at 
Fasteners,  Actuators,  Connectors,  Toois,  and  Subsystems  (FACTS) 

Both  the  International  Data  Corporation  (IDC)  and  Professor  Marvin  Mannheim,  a  noted 
researcher  at  the  Kellogg  School  of  Management  at  Northwestern  University,  have  come  up  with 
some  distinctions  with  which  to  categorize  workflow  systems.  The  IDC  defines  three  categories; 
Production,  Administrative,  and  Ad-Hoc.  Mannheim’s  distinctions,  equally  well  accepted,  are 
similar:  Structured,  Semi-Structured,  and  Unstructured.  Both  sets  of  distinctions  use  category 
labels  that  describe  the  types  of  processes  that  the  category  of  workflow  is  designed  to  automate. 
The  ATI  technology  discussed  above,  for  example,  is  classified  as  “Production”  or  “Structured” 
workflow.  As  illustrated  in  the  PIBO  example,  this  type  of  workflow  is  generally  used  to 
automate  a  complex,  rigid  process.  ATI’s  methodology  and  technology  is  the  clear  industry 
leader  in  using  this  type  of  workflow  to  automate  this  type  of  process.  Recognizing  this,  QDM 
implemented  this  type  of  workflow  as  part  of  its  initial  Project  Management  deliverable  to  allow 
the  management  of  Projects  and  Tasks  to  be  automated  electronically. 

However,  few  processes  can  be  strictly  and  completely  defined  from  the  outset,  anticipating  and 
allowing  for  the  full  spectrum  of  exceptions  and  contingencies.  QDM,  recognizing  this,  began  to 
develop  Ad-hoc  (or  “Unstructured”)  workflow  tools  for  common  processes  that  do  not  always  fit 
into  a  rigid  pattern  of  work.  As  we  developed  these  tools,  it  became  more  and  more  clear  that 
such  processes  are  generally  pervasive  throughout  an  organization.  These  simple  processes  are 
based  more  on  the  single  Basic  Action  Workflow  loop  than  on  the  complex  series  of  linked 
“conversations”  that  are  used  to  describe  more  complex,  workgroup-specific  processes,  as 
illustrated  in  Figure  12. 


Structured,  Workgroup-specific 
Production  Workflow  for  complex 
processes 
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Planning _ 


Ad-hoc  Workflow  Tools 
for  simple,  pervasive, 
enterprise-  wide 
processes 


Daily  Business 


Figure  12 

Production  workflow  best  automates  complex  processes,  designed  by  the 
management  level  of  the  organization,  for  specific  workgroups.  Ad-hoc 
tools  best  automate  less  defined,  less  predictable,  more  pervasive  processes. 
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A  niche  for  methodologically  sound  ad-hoc  workflow  tools  to  help  people  perform  the  critical 
tasks  that  are  routine  in  the  course  of  daily  business  clearly  existed.  The  most  conunon  such 
process  in  any  working  environment  is  the  simple  act  of  asking  one  of  your  associates  to  perform 
an  activity.  QDM  terms  these  everyday,  ad-hoc  requests  “Action  Items”  and  provides  a  tool  that 
streamlines  the  delegation,  performance,  and  completion  of  these  simple  tasks. 

The  tool  takes  the  form  of  an  electronic-mail-style  document  that  travels  between  the  customer 
and  performer  of  the  Action  Item  as  the  process  progresses.  The  new  action  item  capability 
incorporates  the  Basic  Action  workflow  methodology  by  allowing  a  performer  to  negotiate  a  task 
with  the  customer  prior  to  accepting  the  assignment,  and  will  require  that  the  customer,  rather 
than  the  performer,  declare  satisfaction.  Despite  the  identical  underlying  methodology,  the  Action 
Item  performs  quite  a  different  function  than  an  ATI  workflow  system.  While  the  structured  ATI 
implementation  requires  the  execution  of  exact  steps  of  the  workflow  based  on  predefined  rules, 
the  flexible  QDM  adaptation  provides  simple,  fundamental  tools  that  are  available  for  use  when 
needed  as  dictated  by  business  situations.  These  tools  epitomize  the  Ad-hoc  or  “Unstructured” 
workflow  category. 

QDM’s  Ad-hoc  workflow  tools  are  “Forms-based,”  a  technological  distinction  that  has  significant 
practical  ramifications.  Stated  simply,  the  “intelligence”  (e  g.,  the  rules  for  what  step  should 
occur  next  based  on  certain  conditions)  behind  the  routing  of  “forms-based”  workflow  tools  is 
contained  within  the  form  itself  The  Action  Item,  for  example,  has  logic  built  right  into  it  that 
routes  the  form  and  changes  its  state  based  on  the  actions  that  have  been  taken  on  it.  Conversely, 
production  workflow  tools  must  “look  up”  the  “rules”  for  routing  before  they  can  be  processed. 
These  “rules”  are  generally  contained  within  a  separate  database  in  a  different  location  on  the 
server. 

What  all  this  technology  means  from  a  practical/usage  standpoint  is  that  a  user  of  a  production 
workflow  tool  needs  to  be  directly  connected  to  the  server  containing  the  routing  “rules”  in  order 
for  progress  to  be  achieved  in  the  workflow  in  a  single,  timely  step.  Ad-hoc  tools,  on  the  other 
hand,  can  be  used  throughout  a  distributed  envirorunent  and  across  geographic  locations  as  simply 
as  sending  an  electronic  mail  message.  An  example  will  help  illustrate;  Charlene  works  at 
corporate  headquarters  in  Charlotte,  Larry  at  a  field  site  in  Los  Angeles.  If  Larry  wants  to  take 
action  in  one  of  Charlene’s  production  workflow  processes,  he  will  need  to  dial  into  her  system  in 
Charlotte  and  communicate  his  work  via  modem  in  order  for  it  to  be  processed.  If,  on  the  other 
hand,  Charlene  has  assigned  Larry  some  work  with  an  Ad-hoc  tool  like  an  Action  Item,  progress 
in  the  workflow  process  can  be  achieved  simply  and  inunediately  through  electronic  mail. 

QDM  used  Application  Programming  Interface  (API)  code  and  forms-based  routing  rules  to 
create  the  logic  for  several  ad-hoc  workflow  tools.  Like  the  Action  Item  form,  these  tools  each 
embody  common,  pervasive  business  processes.  Gathering  input,  building  consensus,  and 
soliciting  approval  are  the  types  of  simple  activities  that  are  critical  to  the  process  of  getting  work 
done  on  a  daily  basis.  The  additional  forms-based  tools  that  were  developed  at  this  stage  of  the 
effort  included  the  Brainstorm,  Opinion  Poll,  and  Request  Approval  forms.  These  provide  users 
with  the  ability  to  automatically  solicit  and  tally  group  input  and  opinions  and  to  route  a  request 
for  approval  through  the  appropriate  chain  of  command  in  much  the  same  way  the  Action  Item 
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automates  the  assignment  and  tracking  of  individual  responsibilities.  The  four  forms,  taken 
together,  are  now  known  as  “Routing  Forms.” 

The  ad-hoc  functionality  was  fully  mtegrated  with  FACTS ’s  existing  production  workflow  syston 
and  with  individual  users’  mail  files.  While  the  production  workflow  processes  took  place  entirely 
within  FACTS’s  central,  shared  Lotus  Notes  database,  individual  ad-hoc  Routing  Forms  are 
merely  initiated  there.  As  users  act  on  Routing  Forms  in  their  Mail  files,  the  copy  of  the  form  in 
the  shar^  database  is  updated  with  their  progress.  The  shared  database  is  the  central  site  for 
teamwork,  individual  Mail  files  are  the  central  site  for  individual  responsibility,  as  shown  in 
Figure  13. 


Figure  13 

Basic  interaction  between  databases  and  Mail  files.  Ad-hoc  processes  are  accomplished 
in  the  Mail  file,  more  complex  production  processes  are  governed  in  workflow- 
enabled  shared  databases,  and  status  of  each  type  of  process  is  passed  between  locations. 

Quality  Decision  Management’s  Commercial  Efforts  in  Parallel  with 
Phase  II  Small  Business  Innovation  Research  Effort 

As  QDM  developed  our  early  adaptations  of  ATI’s  production-based  workflow  and  our  own 
forms  routing  based-workflow  for  the  SBIR  effort,  we  recognized  the  strong  potential  for 
immediate  commercialization  of  this  SBIR  technology.  Lotus  Notes  had  been  on  the  market  for 
more  than  two  years,  and  the  installed  base  was  reaching  the  300,000  user  mark.  As 
organizations  adopted  Lotus  Notes,  they  began  to  realize  the  amount  of  time  and  resources 
required  to  develop  and  deploy  applications  designed  to  operate  in  the  Lotus  Notes  environment. 
The  notion  of  off-the-shelf  applications  had  considerable  appeal  to  the  Lotus  Notes  market,  and 
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QDM  seized  this  opportunity  to  commercialize  the  SBIR  technology  into  a  ready-to-use 
workflow-enabled  Lotus  Notes  product. 

QDM  conducted  our  own  unofficial  Phase  m  SBIR  effort  in  parallel  with  our  ongoing  Phase  11 
effort.  Using  funds  secured  from  private  investment  capital,  QDM  added  additional  features  and 
functions  to  the  SBIR  workflow  technology.  We  entered  into  an  agreement  with  ATI  to  license 
the  Workflow  Management  Server  engine  and  ship  it  as  part  of  a  commercial  product.  We 
conducted  a  rigorous  test  of  the  software  and  produced  the  necessary  product  documentation  and 
packaging,  ^^th  these  efforts,  in  March,  1993,  QDM  launched  a  commercialization  of  the  SBIR 
technology  called  Quality  At  Work*,  Version  2.0.  (QDM  had  previously  introduced  a  suite  of 
Lotus  Notes  applications  which  were  trademarked  Quality  At  Work.) 

The  Final  Workflow  Prototype:  A  Licensed,  Fasteners,  Actuators,  Connectors, 
Tools,  and  Subsystems  (FACTS)-Specific  Customization  of  Quality  Decision 
Management’s  Quality  At  Work* 

To  ensure  that  the  FACTS  office  had  the  latest  technology,  QDM,  under  a  specification  agreed  to 
in  a  modification  to  the  SBIR  contract,  agreed  to  transition  the  FACTS  Project  Management 
system  to  an  underiying  architecture  of  the  commercial  version  of  QDM’s  Quality  At  Work. 
Quality  At  Work  was  furnished  to  this  organization  because  the  expanded  Workflow  and 
Graphical  Front  End  technology  offers  the  widest  range  of  functionality  and  is  easily  maintained 
even  beyond  the  conclusion  of  this  SBIR  effort.  The  commercial  version  of  Quality  At  Work  will 
not  be  ffimished  as  part  of  the  formal  software  deliverable  at  the  conclusion  of  this  effort,  with  the 
exception  of  the  license  granted  to  FACTS.  Other  Government  offices  that  choose  to  operate  the 
fully  expanded  prototype  system  will  be  required  to  purchase  necessary  commercially  available 
software,  such  as  Lotus  Notes  and  Quality  At  Work. 

The  Quality  At  Work  system  represents  a  more  advanced  maturation  of  the  core  technologies 
that  QDM  developed  and  delivered  to  the  FACTS  Office  for  the  SBIR  effort.  This  system 
integrated  multiple  Lotus  Notes  databases,  all  of  which  were  equipped  with  Quality  At  Work 
Routing  Forms.  Each  database  was  also  fully  integrated  with  individual  Mail  files  per  the  Quality 
At  Work  paradigm. 

The  three  databases  that  form  the  core  of  the  FACTS  Quality  At  Work-hdised  architecture  are  the 
Problem  Documentation  database,  the  Project  database,  and  the  Closed  Project  database.  A 
fourth  database.  Customer  Feedback,  provides  a  collection  point  for  all  “customer  issues”  that  are 
generated  on  behalf  of  FACTS  customers  from  the  other  three  databases. 

The  Problem  Documentation  database  houses  reports  generated  by  FACTS  “field  service  visits.” 
Based  on  the  findings  detailed  in  these  reports,  a  decision  is  made  whether  or  not  to  begin  an 
“official”  FACTS  project.  Those  investigations  resulting  in  new  FACTS  projects  are  initiated  in 
the  Problem  Documentation  database  by  composing  a  new  project  summary  document.  Once 
initiated,  the  new  project  summary  will  by  copied  (using  QDM’s  forms  routing  engine)  to  the 
FACTS  Project  database  where  it  A\dll  be  worked  until  completed.  Completed  projects  are 
archived  in  the  Closed  Projects  database.  The  basic  architecture  is  shown  in  Figure  14. 
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Figure  14 

Basic  architecture  of  FACTS-speciTic  customization  of  Quality  At  Work.  In  addition 
to  the  Problem  Documentation,  FACTS  Project,  and  Closed  Project  databases, 
a  Feedback  database  (not  pictured)  gathers  comments  from  the  three  others. 

The  Project  database  was  streamlined  to  match  the  FACTS  process  while  maintaining  existing 
project  management  capabilities  that  had  been  implemented  earlier  (as  detailed  above).  In  fact, 
this  process  is  very  similar  indeed  to  the  PIBO  process  that  we  had  initially  automated  with 
production  workflow.  The  biggest  difference  between  the  two  systems  is  that  this  iteration  is 
much  more  flexible  because  of  the  addition  and  integration  of  ad-hoc  workflow  tools.  For 
example,  rather  than  automatically  assuming  the  steps  in  the  workflow  (assign  team  leader,  assign 
tasks,  etc.),  the  workflow  forms  are  there  for  the  user  to  use  when  and  if  appropriate.  In  addition 
to  providing  users  with  this  flexibility,  these  tools  also  tightly  integrate  individual  Mail  files  with 
the  databases  which  house  the  processes.  Users  are  more  completely  and  effectively  involved  in 
the  process  because  of  the  design  of  the  ad-hoc  workflow  tools  and  the  system  architecture. 

Lotus  Notes  is  an  excellent  enwonment  that  offers  access  to  public  and  private  workspace.  Mail 
is  a  private  space  database.  Problem  Documentation,  FACTS  Projects,  and  Closed  Projects  are 
public  databases.  In  a  routine  Lotus  Notes  installation,  these  databases  would  be  separate  islands 
of  information.  Breakdowns  can  occur  as  information  and  work  assignments  begin  to  accumulate 
in  these  separate  islands.  The  QDM  design  does  not  treat  databases  as  separate  islands  of 
information  but  creates  connectivity  that  models  the  process  and  monitors  the  status  of  work 
among  and  between  databases.  As  opinions  are  solicited  from  the  public  FACTS  Projects 
database,  an  Opinion  Poll  form  is  routed  to  the  private  mail  database  of  the  people  involved  in 
that  specific  process.  There  is  no  risk  that  the  intended  respondents  will  overlook  the  request. 
Work,  in  this  case  the  response  to  the  Opinion  Poll,  is  conducted  in  the  users’  private  mail 
database,  but  the  response  is  automatically  routed  back  to  the  public  FACTS  Projects  database. 
As  group  consensus  accumulates,  everyone  can  view  the  collective  input. 

This  design  creates  a  closed-loop  feedback  system  that  is  vital  to  the  successful  coordination  of 
group  activity.  The  QDM  architecture  is  an  effective  integration  of  private  and  public  space  that 
ensures  the  benefits  of  improved  information  access  without  the  burden  of  excessive  information 
overload. 
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When  a  project  is  completed,  the  entire  project  (project  summary  and  all  related/relevant 
documents)  is  moved  to  the  FACTS  Closed  Project  database.  The  Project  Summary  document  is 
maintained  by  Quality  At  Work  across  all  three  dat^ases.  Linking  the  entire  FACTS  process  via 
the  Quality  WoHi  architecture  in  this  way  provides  an  integrated  groupware  system  of 
workQow-enabled  databases  from  which  accurate  metrics  can  be  gathered  and  displayed  by  an 
intelligently  designed  Graphical  User  Interface. 

Process-Oriented  Front  End  Module 

The  front  end  is  a  crucial  piece  of  the  Groupware  System  for  Multidisciplinary  Participation.  In 
order  to  maximize  the  ability  of  the  front  end  to  foster  and  facilitate  process  awareness,  the  tool 
must  be  embraced  by  the  user  community.  The  best  way  to  create  this  acceptance  is  to  make  the 
tool  powerful,  and  easy  to  use  and  understand. 

The  power  of  the  GUI  stems  from  its  ability  to  read  and  display  data  from  the  workflow  module, 
whose  user  interface  is  somewhat  limited  by  comparison.  One  example  of  this  limitation  is  that 
the  Lotus  Notes  platform,  though  allowing  any  number  of  sophisticated  and  informative  views  of 
an  individual  database,  is  unable  to  compile  information  across  numerous  databases.  For  example, 
a  user  of  the  Lotus  Notes  interface  would  not  be  able  to  view  all  projects  being  performed  on 
behalf  of  a  ^ven  customer  in  all  databases  (i.e..  Sales  Project,  Consulting  Services  Project, 
Customer  Complaint  Resolution,  etc.)  throughout  the  system.  A  well-designed  GUI  could 
compile  that  data  easily. 

Lotus  Notes  views,  in  addition  to  being  confined  to  the  data  in  a  single  database,  are  also 
relatively  fixed  as  compared  to  the  dynamic  user-defined  queries  of  a  process-oriented  front  end. 
Adding  or  modifying  views  in  Lotus  Notes  requires  programming,  but  shifting  the  focus  of  the 
query  for  information  in  a  GUI  can  be  as  easy  as  pressing  a  button.  For  example,  someone 
interested  in  the  ZBT  Corporation  can  take  a  view  of  the  projects  being  done  for  them  and  see 
that  several  are  running  late.  A  process  view  will  show  where  the  bottlenecks  are.  Digging 
deeper  will  show  who  is  responsible  for  performing  the  processes  that  are  holding  things  up. 

Users  of  a  GUI  are  able  to  gather  the  information  they  seek  by  dynamically  adjusting  the  focus  of 
their  queries,  zooming  in  or  backing  out  “on  the  fly,”  rather  than  constantly  shifting  between  a 
predefined  set  of  Lotus  Notes  views. 

Another  limitation  of  the  Lotus  Notes  user  interface  is  that  it  is  largely  text-based.  Views  of  a 
given  database’s  information  take  the  form  of  indented  outlines.  A  process-oriented  front  end 
module  could  not  only  compile  this  information  with  that  of  other  databases,  it  could  also  display 
the  results  in  colorful,  easy-to-understand  charts  and  graphs.  Bar  charts  and  process  maps  are 
much  more  informative  and  user-fiiendly  than  text  outlines.  They  are  also  analyzed  much  more 
readily,  giving  users  insights  into  the  way  processes  are  being  performed  and,  more  importantly, 
how  they  can  be  improved. 

From  the  beginning,  QDM  established  criteria  for  selecting  a  robust,  user-friendly  GUI  wifh  which 
to  display  data  gleaned  from  the  workflow  module  of  the  SBIR  effort.  These  criteria  included; 
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*  a  tool  that  could  graphically  depict  a  process  both  as  a  whole  and  as  the  sum  of  its 
individual  parts, 

*  relational  functionality  that  contextualizes  a  user’s  role  and  activities  within  the  process, 

*  information  visualization  tailored  to  the  way  a  user  easily  understands  data  (i.e.,  use  of 
pictures,  graphics,  charts,  numbers,  words), 

*  reporting  standards  that  provide  status  and  feedback  about  the  process  and  individual 
components  of  the  process  to  users,  and 

*  convenient  access  to  different  data  sources  and  different  data  types. 

As  our  original  intent  was  to  use  existing  technology,  not  invent  a  new  graphical  interface, 
identifying  these  criteria  proved  to  be  a  much  simpler  task  than  finding  a  GUI  tool  that  met  them. 

The  Failure  of  Notebook  as  a  Candidate  Environment  for  the  Phase  II  Front  End 

In  the  initial  stages  of  our  search  for  a  GUI  tool  with  which  to  build  a  Process-Oriented  Front 
End,  QDM  acquired  access  to  a  toolset  in  the  preliminary  stages  of  development  from  Lotus 
Development  Corporation,  code-named  Notebook.  During  the  Phase  I  Modification  stage  of  our 
SBIR  effort,  QDM  evaluated  Notebook’s  viability  as  a  tool  for  building  the  Process-Oriented 
Front  End  to  our  system.  QDM  was  uniquely  qualified  to  perform  this  evaluation;  we  were 
working  closely  with  the  Lotus  Development  Corporation  as  a  Notebook  Design  Partner.  Thus, 
we  could  not  only  evaluate  Notebook  as  a  tool,  but  also  influence  its  design  with  requirements, 
suggestions,  and  feedback  such  that  the  functionality  we  desired  could  be  incorporated  into  the 
commercial  version  of  the  product. 

Our  intention  was  to  build  a  demonstration  with  Notebook  operating  as  the  interface  to  the  PIBO 
workflow  application.  The  purpose  of  the  Notebook  demonstration  was  to  provide  a  mock-up  of 
the  process-oriented  GUI  in  the  early  stages  of  the  SBIR  project.  Throughout  this  period  of 
activity,  we  continued  to  test  Notebook  capabilities  in  an  attempt  to  build  the  required  mock-up 
system.  The  result  of  this  testing  and  research  proved  that  the  pre-alpha  version  of  Notebook  was 
severely  limited.  Although  the  eventual  release  of  Notebook  was  planned  to  support  many  of  the 
functions  required  for  our  development  effort,  completing  anything  more  than  a  limited 
demonstration  using  Notebook  in  its  available  state  was  not  possible. 

This  demonstration  marked  the  be^nning  of  the  difficulties  presented  by  Notebook.  The  product 
was  supposed  to  include  very  useful  features,  including  data  access  (to  Sybase*,  dBase* 

Informix*  Paradox*  Lotus  Notes*  and  1-2-3*),  a  script  language,  Dynamic  Data  Exchange 
(DDE)  client  and  server.  Object  Linking  and  Embedding  (OLE)  client,  and  full-featured 
WYSIWYG  (computer-ese  for  What  You  See  Is  What  You  Get)  GUI  with  menu  builder  and 
user-programmable  smart  icons.  Although  these  features  would  have  proved  quite  helpful  in 
developing  our  Process-Oriented  Front  End,  the  Notebook  production  schedule  continued  to  slide 
and  prereleased  bugs  continued  to  hamper  our  SBIR  development  efforts. 
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QDM  realized  more  than  18  months  ago  that  these  limitations  would  prohibit  the  delivery  of  a 
functional  GUI  in  the  SBIR  time  frame  and  discontinued  further  development  work  with  the 
Notebook  toolset.  Despite  this  product’s  brief  reemergence  as  a  viable  candidate  several  months 
later  (due  to  some  changes  in  Lotus’  development  strategy),  this  decision  proved  to  be  an 
intelligent  one.  Notebook,  now  called  “Notes  ViP,’’  was  announced  and  demonstrated  at  the 
Lotusphere  ‘93  conference  in  December  1993,  but  remains  far  behind  our  schedule  and  unreleased 
at  this  writing. 

Exploring  Other  Candidates  for  Graphical  User  Interface  Development 

During  this  period,  QDM  also  met  with  representatives  from  the  Trinzic  Corporation  (known  at 
that  time  as  Channel  Computing)  to  discuss  the  possibility  of  using  its  product  Forest  &  Trees*  as 
the  development  envirorunent  for  the  GUI.  Forest  &  Trees  contains  customized  application 
development  tools,  performs  data  retrieval  across  a  wide  range  of  platforms,  and  consists  of  a 
User  Interface  (UI)  to  graphically  present  information  in  a  variety  of  ways. 

One  feature  of  Forest  &  Trees  that  was  especially  attractive  in  our  case  is  that  the  product  is 
designed  to  run  like  an  electronic  dashboard  monitoring  specified  data.  It  also  comes  standard 
with  links  to  common  data  formats  such  as  1-2-3,  Excel*,  dBase,  and  Paradox.  Links  are  also 
optionally  available  for  several  SQL-based  data  systems.  As  this  product  was  more  mature  than 
Notebook  and  already  incorporated  important  required  features  (“gauges”  to  monitor  data, 
programmable  zones  on  the  screen,  a  very  flexible  UI),  we  considered  the  use  of  tWs  product  as 
the  basis  for  our  UI. 

Another  important  player  in  the  user  interface  evaluation  was  the  Design  OA*  environment  from 
Meta  Software  Corporation.  QDM  used  Design  OA  as  the  development  environment  for  Memory 
Jogger  Plus+  PC™,  our  seven  management  and  planning  tools  software  product.  Design  OA  was 
used  much  like  one  would  use  ObjectVision*  or  Forest  &  Trees  to  build  a  custom  application, 
including  extensive  C  programming  interface  with  the  Design  OA  libraries. 

Although  the  benefits  to  both  Design  OA  and  Forest  &  Trees  are  often  tremendous,  serious 
limitations  to  using  such  products  as  the  basis  for  customized  application  development  can  exist. 
The  most  important  benefit  is  the  ability  to  take  advantage  of  proven,  existing  technology,  which 
can  save  considerable  development  time  and  effort.  The  most  serious  limitation  was  that  we 
could  only  make  our  application  do  what  the  software  vendors  allowed  us  tc  by  using  features 
compiled  into  the  product.  Even  using  programming  interface  languages,  we  were  limited  to 
working  with  the  designed  features  compiled  in  object  libraries. 

QDM  encountered  several  instances  of  this  limitation  while  developing  our  Memory  Jogger* 
product.  Several  desirable  capabilities  such  as  DDE,  floating  palettes,  and  smart  icon  bars  were 
not  included  in  the  product  and  were  unavailable  because  we  did  not  have  access  to  the  Design 
OA  source  code.  Thus,  as  a  candidate  for  the  SBIR  development.  Design  OA  presented  these 
same  limitations. 

To  combat  this  problem,  QDM  (separate  from  the  SBIR  contract)  purchased  the  source  code  to 
Design  OA  for  both  Windows  and  the  Macintosh  from  Meta  Software.  We  started  to  familiarize 
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ourselves  with  the  code  to  detemune  how  to  modify  the  environment  for  our  SBIR  requirements. 
Unfortunately,  the  source  code  proved  difficult  to  manage;  much  code  reorganization  would  have 
been  necessary  for  us  to  achieve  our  desired  results.  Also,  despite  Design  OA’s  power  as  a 
long-term  platform,  it  did  not  prove  agile  enough  as  a  prototype  environment  to  handle  QDM’s 
iterative  Rapid  Prototype  Development  Approach. 

Many  other  candidates  were  thoroughly  evaluated  as  possible  environments  in  which  to  develop 
the  Process-Oriented  Front  End.  In  addition  to  the  three  products  discussed  above,  QDM  also 
examined  products  such  as  Object  Vision*,  Toolbook*  Neuron  Data’s  Open  Interface*  and 
Corporate  Memory  Systems’  CM/1*.  Such  evaluations  continued  through  early  1993  when,  after 
rigorous  testing,  QDM  settled  on  Microsoft’s  Visual  Basic  2.0*  as  the  nroduction  environment 
for  the  Graphical  Front  End. 

Visual  Basic  2.0:  Production  Environment  for  the  Graphical  Front  End 

Visual  Basic  was  chosen  on  the  basis  of  its  being  an  established,  well-respected  and  supported 
product  that  has  the  capability  to  read  information  from  the  workflow  module  and  then  clearly 
display  it  graphically  in  a  variety  of  user-defined  formats.  Our  investigation  into  the  variety  of 
GUI  candidates  made  it  clear  that  the  actual  user  interface  was  just  as  important  as  the  tool’s  data 
acquisition  .  >  4  ^  lities.  Visual  Basic  provided  us  with  a  strong  blend  of  these  two  important 
concepts  li  .  ided  us  with  the  requisite  flexibility,  clarity,  and  graphical  sophistication  for  our 
Process-Oriented  Front  End. 

The  overall  functional  objectives  of  the  Process-Oriented  Front  End  were  to  provide  the 
following. 

«  Flexible,  User-Definable  Queries.  Allow  users  to  focus  on  specific  information  according 
to  their  individual  needs  and  interests.  Enable  users  to  get  the  information  they  want, 
rather  than  being  restricted  to  a  limited  set  of  pre-defined  views. 

*  Graphical  Displays  of  Processes.  Display  the  results  of  these  queries  in  a  clear,  concise 
manner.  These  displays  should  contain  current  statistics  and  historical  information  about 
processes  in  the  system. 

Contextualized  Information.  Make  clear  to  the  user  the  context  of  the  displayed  . 
information.  This  clarification  will  facilitate  analysis  of  the  data  and  help  target  areas  for 
action. 

The  Process-Oriented  Front-End  Graphical  User  Interface  is  designed  to  format  and  display 
information  generated  in  the  workflow  module  and  present  it  to  users  in  a  manner  that  fosters  and 
facilitates  analysis. 
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The  system  functions  follow: 

*  Data  acquisition  from  the  workflow  module.  The  power  to  read  data  and  generate 
graphs  and  tables  that  reflect  this  data  in  a  reasonable  amount  of  run-time. 

*  User  definition  of  selection  criteria.  An  initial  design  that  makes  it  easy  fcr  users  to 
define  their  specific  information  needs. 

*  Toob  that  foster  and  facilitate  process  analysb.  Carefully  designed  to  enable  users  to 
fully  understand  the  business  processes  and  to  use  this  knowledge  to  analyze  and  improve 
the  flow  of  work  through  the  organization. 

Of  course,  the  first  step  in  designing  the  GUI  was  providing  it  with  the  means  to  read  the  data 
fi'om  the  workflow  module.  Through  our  thorough  investigation  of  candidate  environments,  it 
became  evident  that  no  available  graphical  development  environments  directly  accessed  Lotus 
Notes  databases  without  additional  custom  development.  QDM  developed  a  program  that  would 
essentially  serve  as  a  Lotus  Notes  Data  Pump,  transferring  Lotus  Notes  data  from  the  databases  in 
which  it  resided  (known  in  Lotus  Notes  as  .NSF  files)  into  Visual  Basic  files  that  could  be  read 
and  processed  by  the  Front  End.  The  Lotus  Notes  Data  Pump  is  shown  graphically  in  Figure  15. 


Figure  15 

Basic  architecture  of  the  Data  Pump  developed  by  QDM  to  transfer  data 
from  Lotus  Notes  to  the  Process-Oriented  Front  End 

The  initial  prototype  allowed  for  graphics  to  be  generated  from  two  primary  foci:  customers  for 
whom  work  was  being  performed  or  employees/team  members  who  were  responsible  for 
performing  it.  Figure  16  shows  the  initial  configuration. 
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Figure  16 

Opening  screen  of  initial  prototype  GUI.  First  level  of  user-defined 
query  was  either  Customer  (for  whom  work  was  being  performed)  or 
Team  (person/people  who  were  responsible  for  performing  it). 

The  results  of  these  user-defined  queries  were  graphically  displayed  in  a  way  that  facilitates 
analysis.  Charts  and  graphs  concisely  conveyed  information  that  increases  awareness  of  business 
processes  and  the  ways  in  which  they  might  be  improved.  Users  will  use  the  graphical 
presentation  of  this  data  to  help  them  identify  and  assess  process  bottlenecks,  individual 
productivity,  and  areas  for  improvement.  This  interface  provided  two  graphical  displays  of  the 
progress  of  either  type  of  information;  state  or  status.  State  identifies  the  processes’  location  in 
the  pipeline  or  steps  of  the  workflow,  as  illustrated  in  Figure  17. 
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Figure  17 

Example  of  a  State  or  Pipeline  view  generated  using  the  initial  prototype 
of  the  Process-Oriented  Front  End.  Additional  information  is  available 
by  selecting  a  given  Customer,  Process,  or  State. 

The  State  or  Pipeline  view  illustrated  above  gives  users  a  more  complete  understanding  and 
awareness  of  the  steps  required  to  complete  a  process.  With  this  awareness  often  comes  insight 
into  where  bottlenecks  are  and  how  the  process  might  be  improved;  Are  projects  slow  to  be 
accepted  or  completed?  Are  a  large  percentage  of  projects  being  rejected  or  canceled?  Are  these 
trends  acceptable  or  indicative  of  poor  practices? 

The  status  display  illustrates  the  timeliness  of  a  process,  as  shown  in  Figure  18.  As  opposed  to 
seeing  a  detailed  view  of  the  process  and  how  work  is  flowing  through  it,  this  view  examines  the 
entire  process  as  a  unit  and  measures  it  against  its  initial  time  estimate.  One  example  of  the  use  of 
the  status  ^dew  would  be  to  delve  into  the  nature  of  processes  that  are  running  late.  Is  a  given 
performer  common  to  many  such  processes?  Are  the  initial  time  estimates  reasonable?  How  can 
operations  be  improved  to  ensure  that  scheduling  is  accurate  and  that  work  gets  done  on  time? 
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Figure  18 

Example  of  a  Status  view  generated  using  the  initial  prototype  of  the  Process- 
Oriented  Front  End.  Additional  information  is  available  by  selecting  a 
given  Customer,  Process,  or  Status  category  (e.g.  On  Time,  Late,  etc.). 

The  overall  design  of  the  graphical  front  end  presented  information  from  a  management  and  user 
workstation  overview.  The  initial  GUI  prototype  displayed  statistical  analysis  of  the  current  state 
(or  a  historical  state)  of  sets  of  processes  that  met  some  specified  criteria.  In  contrast  to 
pre-defined  Lotus  Notes  views,  this  interface  allowed  the  user  to  select  check  boxes  and  radio 
buttons  until  the  desired  set  of  documents  was  located.  Rather  than  being  restricted  by  a  Lotus 
Notes  view  to  documents  in  a  single  database,  the  user  of  this  interface  had  the  ability  to  compile 
information  that  is  read  from  documents  across  multiple  databases. 

The  Final  Front-End  Prototype:  Fasteners,  Actuators,  Connectors,  Tools,  and 
Subsystems  (FACTS)-Specific  Project  Monthly  Review  Reporting  System 

The  response  to  this  iiutial  prototype,  and  to  the  FACTS-specific  Project  Management  workflow 
system,  was  positive  enough  to  warrant  further  development  and  customization  of  these  tools  for 
the  FACTS  office.  Additional  functionality  was  added  to  the  baseline  GUI  prototype  to  create  a 
Front  End  that  could  quickly  generate  the  types  of  charts  that  are  typically  included  in  FACTS 
office  monthly  reports.  These  modifications  were  requested  by  the  FACTS  office  after  it  had 
experimented  with  the  original  software  deliverables  in  a  pilot  environment.  FACTS  personnel 
discovered  that  these  technologies  could  be  extremely  useful  as  part  of  their  standard  ways  of 
doing  business.  For  example,  they  could  access  summary  and  statistical  information  at  any  time, 
rather  than  compiling  the  data  each  time  in  preparation  for  a  status  briefing.  As  a  result,  FACTS 
asked  QDM  to  customize  the  workflow  and  GUI  tools  to  fit  their  needs  (see  Figure  19.) 
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Figure  19 

Opening  screen  of  FACTS-specific  prototype.  In  addition  to  Project 
and  People  foci,  Monthly  and  Summary  reports  are  also  available. 

In  addition  to  the  Project  and  Team  member  foci  offered  by  the  initial  prototype,  the 
FACTS-specific  Program  Monthly  Review  (PMR)  also  gave  users  the  ability  to  generate  monthly 
and  yearly  project  summaries  (the  two  buttons  on  the  far  right  of  the  screen  above).  Monthly 
summaries  display  a  bar  chart  of  the  pipeline  states  of  all  projects  across  every  branch  of  the 
FACTS  office  for  a  given  month  and  year.  Yearly  summaries  offer  “By  Status”  and  “By  Team” 
views  of  projects  for  a  given  fiscal  year.  Pipeline  information  within  these  summaries  is  broken 
down  by  division/type  of  project  (Fasteners,  Connectors,  Tools,  Subsystems,  Process),  and 
high-level  summaries  of  all  FACTS  activity  are  also  available. 

Additional  FACTS-specific  information  has  also  been  added  to  the  Project  and  People  queries. 
The  four  middle  buttons  on  the  screen  shot  above  (Pipeline,  Financial,  Late/On-Time,  and 
Schedule)  give  FACTS  users  specific,  meaningful  metrics  with  which  to  judge  the  progress  of  the 
office’s  various  processes.  For  example,  the  generic  pipeline  button  that  was  developed  in  the 
initial  prototype  has  been  modified  to  specifically  reflect  the  FACTS  teams  and  process.  When 
FACTS  users  select  the  pipeline  button  (after  having  selected  a  group  of  projects  or  team 
members  about  which  they  would  like  to  generate  these  metrics),  they  are  presented  with  the  set 
of  options  shown  in  Figure  20. 
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Figure  20 

The  list  of  Teams  and  Major  Commands  about  which  FACTS 
users  can  generate  pipeline  and  other  metrics  using  the 
FACTS-specific  Graphical  Front  End 

The  user,  after  selecting  the  Teams  and  Major  Commands  about  which  he  would  like  information, 
is  presented  with  the  Pipeline  view  shown  in  Figure  21. 


Figure  21 

Sample  pipeline  view  of  Tools  Team  projects  for  the  ACC  MajCom.  Note 
that  this  process  outline  specifically  reflects  the  FACTS  process  and,  thus, 
differs  from  the  general  pipeline  view  developed  in  the  initial  prototype  GUI. 


The  Financial  and  Schedule  buttons  in  the  top  right  corner  of  this  screen  give  average 
Cost-Benefit  analyses  and  Actual  vs.  Planned/Baseline  schedules  for  the  selected  set  of  projects. 
The  user  may  click  on  a  given  pipeline  state  to  dig  into  details  of  individual  projects.  The  user  can 
easily  maneuver  within  the  GUI  to  dig  into  deeper  detail  or  to  back  up  to  a  higher  level  and  get 
the  “big  picture”  view.  Queries  can  be  organized  by  project,  team.  Major  Command,  pipeline 
state,  or  any  combination  of  these  factors. 

Using  these  criteria,  FACTS  users  can  also  generate  metrics  with  the  Late/On-Time  button  on  the 
initial  screm  of  the  GUI.  The  Front-End  is  capable  of  quickly  generating  bar  charts  which 
measure  actual  progress  versus  planned  or  baseline  schedules.  These  metrics  can  be  generated  to 
thoroughly  examine  a  single  project  or  to  get  a  general  sense  of  project  progress  within  a  team  or 
MajCom. 

All  of  these  query  possibilities  were  created  in  response  to  specific  requests  made  by  the  FACTS 
office.  The  metrics  generated  are  the  very  ones  used  routinely  by  the  FACTS  office  to  measure 
performance  and  progress  and  by  which  to  gauge  improvement.  The  Process-Oriented  Front  End 
evolved  fi’om  a  generic  Process  Awareness  tool  to  a  bonafide,  FACTS-specific  Project  Monthly 
Review  application. 


Integration  of  Management  Tools 


The  Initial  Proposal 

The  initial  proposal  for  the  Groupware  System  for  Multidisciplinary  Participation  detailed  a  third 
section  of  technology  in  addition  to  the  workflow  and  graphical  front-end  modules.  The  purpose 
of  this  tlurd  section  was  to  provide  generic  tools  that  would  be  widely  useful  when  performing 
analyses  to  justify  decisions,  prioritize  alternatives,  evaluate  options,  and  develop  a  plan  of  action. 
These  tools  were  to  embody  concepts  such  as  Quality  Control  (QC),  Effective  Planning, 
Continuous  Improvement,  and  TQM. 

The  Seven  Quality  Control  tools  that  were  suggested  for  incorporation  into  the  system  are  shown 
in  Figure  22.  They  were  to  implement  the  techniques  of 

♦  Hoshin  Planning, 

♦  QFD, 

♦  Statistical  Process  Control  (SPC), 

♦  Benchmarking, 

♦  Pareto  Charts, 

♦  Flow  Charts,  and 

♦  Cause  and  Effect  Diagrams. 
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Figure  22 

The  Seven  Quality  Control  Tools  that,  per  the  initial  proposal, 
were  suggested  for  the  system.  These  generic  tools  were  replaced  with 
FACTS-specific  tools  in  the  amended  Statement  of  Work. 

In  addition  to  the  QC  tools,  a  series  of  tools  known  as  the  Seven  Management  and  Planning  Tools 
(MP),  shown  in  Figure  23,  was  also  to  be  integrated  into  the  Groupware  System  for 
Multidisciplinary  Participation.  These  tools,  although  a  powerful  means  of  implementing  steps  of 
the  management  decision  process,  were  also  generic.  Rather  than  specifically  addressing  the 
needs  of  the  FACTS  office,  these  tools  were  applicable  to  the  full  spectrum  of  businesses  and 
management  needs.  The  tools,  pictured  below,  are  applied  in  situations  to  first  identify  broad 
category  issues  (brainstorming),  then  narrow  these  creative  ideas  down  to  an  impiementabie  plan 
of  action. 
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Figure  23 

The  Seven  Management  and  Planning  Tools,  as  discussed  in  Michael  Brassard's 
book  The  Memory  Jogger  Plus*,  originally  planned  for  implementation 
into  the  SBIR  system.  Replaced  with  FACTS-specific  tools  in  the  amended 

Statement  of  Work. 

Again,  such  generic  quality  tools,  although  useful,  did  not  meet  the  needs  of  our  newest  set  of 
FACTS  customers.  Rather  than  applying  a  set  of  generic  tools  to  their  processes,  they  preferred 
to  have  a  set  of  tools  developed  that  were  specifically  mapped  to  their  standard  processes  and 
metrics. 

Meeting  the  Changing  Needs  of  our  Small  Business  Innovation  Research 
Customer 

The  FACTS-specific  workflow  module  and  graphical  front-end  required  an  intensive  development 
effort  that  exceeded  the  initial  Statement  of  Work  in  its  comprehensiveness  and  applicability  to  the 
specific  needs  of  the  FACTS  environment.  As  the  workflow  and  GUI  systems  became 
increasingly  more  suited  to  the  FACTS  office,  it  became  clear  that  the  Tools  module  of  the  effort 
should  not  be  a  separate  entity  but,  rather,  should  be  fully  integrated  with  the  other  two  modules. 
With  an  integrated  set  of  tools.  Process  Analysis  would  not  be  an  isolated  exercise,  but  a  dynamic 
part  of  accomplishing  daily  tasks. 

Thus,  rather  than  develop  a  set  of  generic  technologies  that  would  go  unused,  QDM  worked  with 
the  FACTS  office  to  determine  requirements  for  developing  tools  that  would  serve  as  an  integral 
part  of  the  FACTS  office’s  business.  Many  of  these  tools  were  implemented  into  the  custom 
Visual  Basic  Front-End.  Others  formed  the  basic  building  blocks  of  the  workflow  module.  These 
tools,  tightly  integrated  with  the  production  software  system,  make  process  analysis  and  quality 
management  much  more  than  a  mere  intellectual  exercise.  The  Groupware  System  for 
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Multidisciplinary  Participation  brings  these  concepts  out  of  the  realm  of  theory  and  into  the 
practical  world  of  everyday  business.  For  example,  not  only  will  these  tools  generate  metrics  for 
abstract  analysis,  but  they  will  also  create  the  charts  and  graphs  that  must  be  included  in  the 
FACTS  office’s  monthly  reports. 

Process  Anaiysis/Quaiity  Management  Tools  Built  into  the  Fasteners,  Actuators, 
Connectors,  Tools,  and  Subsystems  Graphical  User  Interface 

The  Late/On-Time  button  on  the  startup  screen  of  the  graphical  Front  End  (as  shown  in 
Figure  24)  is  one  powerful  example  of  this  type  of  practic^  process  analysis.  This  button  is  used 
to  generate  bar  charts  which  illustrate  the  number  of  late,  on  time,  and  impending  projects. 
Queries  can  be  organized  by  project,  team.  Major  Command,  or  any  combination  of  these  factors. 
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Figure  24 

Sample  process  analysis  chart  generated  by  the 
FACTS-specific  graphical  Front-End 

Additional  information  can  be  gathered  to  determine,  for  example,  how  late  projects  are,  on 
whom  progress  waits,  the  actual  schedule  as  against  the  planned  and  baseline  schedules,  and  cost 
benefit  analyses.  All  of  these  metrics  and  more  are  built  into  the  FACTS-specific 
Process-Oriented  Front  End  and  are  available  as  needed  at  the  press  of  a  button  (See  Figure  25). 
These  tools  are  more  specific  applications  of  basic  technologies  such  as  the  histogram,  Pareto 
chart,  and  run  chart  generated  using  the  relevant  FACTS-specific  data. 
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Figure  25 

A  sample  few  of  the  many  metrics  that  may  be  graphically 
depicted  and  analyzed  using  the  tools  built  into  the 
FACTS-specific  Graphical  Front  End 

Process  Analysis/Quality  Management  Tools  Built  into  the  Fasteners,  Actuators, 
Connectors,  Tools,  and  Subsystems  Workflow  Module 

The  Process  Analysis  metrics  generated  by  the  GUI  are  augmented  by  tools  in  the  workflow 
module.  For  example,  each  user’s  Mail  template  file  contains  a  variety  of  views  of  ongoing 
processes,  including  assignments  that  need  the  user’s  attention  and  those  on  which  other  people 
are  currently  working.  Simply  by  opening  their  Mail  files,  users  can  see  at  a  glance  the  status  of 
all  processes  in  which  they  are  currently  involved  either  as  participants  or  observers  (shown  in 
Figure  26). 
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Figure  26 

Example  of  the  “My  Pending  Work”  view  that  was  incorporated  into  all 
FACTS  Mail  template  files.  Users  may  use  this  view  to  determine 
the  status  of  ongoing  activity  and  the  person  responsible  for  progress. 

Other  tools  in  the  workflow  module  automate  such  QC/MP  processes  as  brainstorming  ideas, 
prioritizing  alternatives,  justifying  decisions,  and  developing  and  implementing  plans  of  action.  In 
fact,  the  entire  notion  behind  the  development  of  Quality  At  Work  Routing  Forms  was  that  users 
need  simple  tools  to  help  them  consistently  perform  common,  critical  tasks  effectively. 

For  example,  if  users  are  to  use  tools  to  “identify  broad  category  issues”  as  originally  discussed  in 
the  initial  Phase  II  proposal,  why  not  give  these  users  a  powerful,  easy-to-use  tool  that  automates 
this  process?  The  Quality  At  Work  Brainstorm  is  a  workflow-enabled  form  that  pervades  the 
FACTS  Quality  At  Work  system.  From  any  Lotus  Notes  database  within  the  system,  a  user  may 
solicit  open-ended  ideas,  responses,  and  input  on  any  given  topic.  All  recipients’  input  is  collated 
into  the  original  request  form  and  returned  to  the  sender  as  it  comes  in. 

The  workflow-enabled  Opinion  Poll  form  is  designed  to  help  users  prioritize  the  alternatives  that 
present  themselves  as  a  result  of  the  type  of  Brainstorming  activity  discussed  above.  The  Opinion 
Poll,  like  the  Brainstorm  form,  travels  to  any  number  of  recipients  and  returns  their  collected  and 
collated  input  to  the  sender.  The  difference  is  that,  in  an  Opinion  Poll,  the  sender  is  asking  that 
the  recipients  vote  on  a  listed  set  of  alternatives  (perhaps  the  most  common  responses  received  in 
the  Brainstorm)  and  add  comments  that  support  their  choices.  The  results  of  the  recipients’  votes 
are  automatically  calculated  and  displayed  in  a  table,  as  shown  in  Figure  27.  All  the  data  needed 
for  prioritization  is  available  at  a  glance. 
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Figure  27 

Results  section  of  an  Opinion  Poll.  The  current  vote  tally  and 
responses  are  displayed,  along  with  the  names  of  those 
recipients  who  have  yet  to  respond. 

Often  a  clear  alternative  emerges  from  the  Opinion  Poll  results.  In  order  to  take  action  on  this 
new  priority,  it  might  be  necessary  to  build  consensus  about  the  alternative  or  to  have  it  approved 
by  a  group  of  superiors.  The  Quality  At  Work  Request  Approval  form  automates  the  process  of 
achieving  sign-off  from  the  proper  parties.  This  form  may  be  routed  either  serially  to  one 
recipient  at  a  time  or  to  ail  recipients  simultaneously.  Once  approval  is  gained,  implementation  of 
a  plan  of  action  can  begin. 

The  workflow  module  not  only  helps  develop  plans,  it  helps  FACTS  users  act  on  them.  The 
Quality  At  Work  Action  Item  automates  the  process  of  delegating  an  ad-hoc  task  to  a  team 
member.  The  form  travels  between  the  two  involved  parties  and  is  automatically  updated  as  the 
task  is  negotiated,  performed,  and  satisfactorily  completed.  For  more  structured,  group-oriented 
tasks,  FACTS  users  may  use  the  structured  production  workflow  tools  provided  in  the  Problem 
Documentation  and  Project  databases.  As  discussed  above,  the  various  views  in  these  databases 
and  in  personal  Mail  files  are  updated  as  the  projects  are  worked.  Pipeline  views  such  as  the  one 
shown  in  Figure  28  let  users  of  the  workflow  module  know  the  current  status  of  all  ongoing 
activity. 
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Figure  28 

Pipeline  view  in  a  Mail  file.  Status  and  pending  performers  of  all 
ongoing  activities  are  displayed. 

These  views,  fully  integrated  with  the  workflow-enabled  tools  enumerated  above  and  the  many 
metrics-based  charts  and  graphs  in  the  Process-Oriented  Front  End,  help  users  not  only  analyze 
processes  but  also  effectively  perform  them. 

Use  of  the  Technology  in  c  Pilot  Environment 

The  determination  of  a  pilot  site  for  the  Groupware  System  for  Multidisciplinary  Participation  was 
made  based  on  the  answer  to  the  following  simple  question;  Which  candidate  organization  is 
most  ready,  both  technically  and  culturally,  to  implement  a  system  that  will  have  far-reaching 
effects  on  the  way  work  gets  done?  The  ideal  pilot  environment  would  need  three  elements,  a 
technical  infrastructure,  an  organizational  structure,  and  defined  organizational  goals,  that  are 
consistent  with  and  support  the  implementation  of  the  system.  The  groupware  system  and 
methodology  are  at  the  peak  of  their  powers  in  an  organization  that  possesses  a  willingness  to 
change  and  the  technological  infrastructure  to  support  that  goal. 

Production  Workflow  in  the  Product  and  Process  improvement  Business 
Opportunities  Division  — ^  Smaii  Business  Innovation  Research  Phase  i 
Modification  —  April,  1992 

During  Phase  I  of  our  SBIR  effort,  QDM  worked  with  the  FACTS  office  which,  through 
organizational  realignments,  became  part  of  the  Product  and  Process  Improvement  (PI)  Office  of 
CSTI.  CSTI/PI  was  charged  to  manage  acti\dties  to  improve  products  and  processes  which  would 
reduce  operations  and  support  costs  in  new  and  fielded  weapon  systems.  CSTI/PI  managed 
numerous  programs  in  addition  to  FACTS  to  achieve  this  mission,  including  the  PRAM  program, 
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and  the  RAMTIP  program.  The  cornerstone  of  each  of  these  technology  programs  is  process 
improvement  and  effective  collaboration  between  the  many  DoD,  Air  Force  (AF),  and  industry 
components  that  have  a  stake  in  each  program.  Pi’s  goal  is  to  maintain  satisfied  customers  as  it 
supports  technology  insertion,  solves  weapon  system  support  problems,  or  coordinates  AF  and 
industry  technology  development  needs. 

Organizationally,  this  office  was  ideal;  both  the  structure  and  the  goals  of  the  organization  were 
completely  consistent  with  the  implementation  of  groupware.  Its  goals  of  continuous  process  and 
quality  improvement  are  precisely  the  goals  of  the  system  itself  The  fact  that  this  office  was 
trying  to  achieve  and  maintain  these  goals  by  managing  many  activities  across  several  programs 
and  locations  makes  groupware  in  general  and  Lotus  Notes  in  particular  a  very  powerful  platform 
on  which  to  develop  a  solution. 

Recognizing  this,  CSTI/PI  had  been  applying  groupware  to  enhance  its  ability  to  work  together 
and  as  the  framework  for  cooperation  and  continuous  improvement.  It  was  as  ready 
technologically  as  well  as  culturally;  prior  to  the  QDM  pilot  it  had  an  existing  environment  of 
Networked  Personal  Computers  (PCs)  and  was  using  Lotus  Notes  as  its  groupware  platform. 
QDM  developed  the  initial  set  of  Lotus  Notes  applications  used  by  FACTS  and  PI.  In  addition  to 
the  initial  set  of  Lotus  Notes  applications,  QDM’s  efforts  at  CSTI/PI  produced  a  Business 
Tracking  System  (BTS)  to  provide  PI  with  an  integrated  system  to  track,  monitor,  and  collaborate 
on  project  and  program  status.  The  system  consisted  of  a  suite  of  Lotus  Notes  applications, 
integrated  and  monitored  by  an  API  engine  developed  by  QDM.  The  primary  application,  the 
Business  Tracker,  provided  summary  status  information  and  metrics  across  all  PI  projects  in  one 
single  application,  regardless  of  phase  in  the  PI  life  cycle.  The  BTS  represented  the  ffist  step  in 
creating  an  environment  to  monitor  and  improve  processes  across  an  organization. 

Installing  Prototype  Project  Management  Workflow  at  Fasteners,  Actuators, 
Connectors,  Tools,  and  Subsystems  —  January,  1993 

Training  Fasteners,  Actuators,  Connectors,  Tools,  and  Subsystems  Office  in 
Workflow  System  Use  —  February,  1993 

Our  contract  monitor  from  AL/HRGA  attended  the  initial  beta  training  session  on  December  10 
and  1 1  for  the  commercial  product.  Quality  At  Work.  As  Quality  At  Work  is  based  on  the 
technology  developed  under  the  SBIR  effort,  the  beta  training  was  an  opportunity  to  provide 
technology  transfer  and  training.  Beta  training  included  an  overview  of  the  product  architecture, 
use  of  the  product  from  the  end-user  perspective,  installation  of  the  product,  and  customization 
of  the  product  to  a  limited  degree. 

Up  until  this  juncture,  it  was  clear  that  the  appropriate  organization  with  which  to  work  as  a 
testbed  was  the  FACTS  Office.  We  had  worked  with  the  organization  during  Phase  I  when 
FACTS  was  a  separate  organization  in  ALD  and  continued  to  work  with  FACTS  as  it  was 
reorganized  under  CSTI/PI.  As  we  proceeded  to  develop  the  next  phase  of  prototype  technology, 
another  reorganization  occurred.  The  FACTS  Office  became  a  separate  entity  once  again, 
moving  to  become  part  of  SM,  the  Subsystems  System  Program  Office  (SPO).  The  majority  of 
CSTI,  including  the  former  FACTS  Director  Col.  Joseph  Kruppa,  were  reorganized  as  the 
Technology  Transition  Office  (TTO). 
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The  result  of  this  latest  reorganization  was  two  candidate  test  environments,  both  of  which  used 
Lotus  Notes  extensively  to  conduct  daily  business  and  had  a  strong  commitment  to  process 
improvement.  As  FACTS  had  provided  the  funding  for  the  effort,  we  decided  to  transition  our 
SBIR  test  site  to  the  new  home  for  FACTS.  Once  again,  QDM  had  to  introduce  the  effort  and 
the  technology  to  new  management  in  the  organization;  we  traveled  to  Wright-Patterson  Air 
Force  Base  (WPAFB)  to  do  so.  This  latest  reorganization  resulted  in  a  significant  downsizing  of 
the  testbed,  as  we  went  from  a  commitment  for  an  entire  organization  to  use  the  technology  to  a 
small  subset  of  the  organization  using  the  technology  on  a  limited  basis. 

We  worked  with  our  Air  Force  point  of  contact  to  identify  the  Tools  Team  as  a  likely  test  site. 
Plans  were  made  to  brief  the  SBIR  effort  at  the  FACTS  Office  Staff  meeting  and  to  meet  with  the 
Tools  Team  to  describe  the  next  steps  for  their  participation  in  the  project.  In  addition,  we 
established  that  the  C-130  Air  Scoop  team  would  also  participate  in  the  test  phase.  This  team  is 
representative  of  a  multidisciplinary  workgroup,  with  members  from  project  management, 
engineering,  and  process  improvement. 

Through  a  series  of  meetings  held  at  WPAFB,  we  were  able  to  coordinate  the  efforts  of  the 
FACTS  test  bed  and  define  the  specific  requirements  for  the  Tools  Team  prototype.  We 
determined  that  we  would  use  the  FACTS  Projects  Folders  database  as  the  baseline  and  modify 
the  existing  Lotus  Notes-based  database  to  incorporate  the  SBIR  workflow  technology  We  also 
discussed  requirements  to  incorporate  SBIR  technology  into  the  mail  template  files. 

We  explained  the  difference  between  a  standard  Lotus  Notes  database,  which  is  just  a  public 
repository  of  information,  and  a  workflow-enabled  Lotus  Notes  database,  which  not  only  contains 
such  public  information  but  also  interacts  with  user  Mail  files  to  incite  action.  Per  the  Basic 
Action  Workflow  model  described  previously,  this  action  is  conducted  between  two  individuals  in 
a  closed-loop  feedback  system.  Status  updates  are  passed  to  the  public  database  from  which  the 
assigirment  was  generated  as  work  is  completed  in  user  Mail  files  (illustrated  in  Figure  29). 
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Figure  29 

A  worWIow-enabled  shared  database.  Work  is  generated  and 
tracked  in  the  public  space  as  individual  progress  is  made  in  private  Mail  files. 

Prior  to  this  effort,  the  FACTS  Projects  Folders  application  was  a  relatively  straightforward  Lotus 
Notes  database  that  summarized  details  about  FACTS  projects  and  recorded  progress  and  activity 
relative  to  the  accomplishment  of  each  project.  Based  on  the  results  of  our  discussions,  we 
agreed  to  modify  the  main  Project  Summary  form  to  incorporate  the  SBIR  workflow  technology 
and  to  include  in  the  databases  and  user  Mail  files  the  Routing  Forms  discussed  previously  in  this 
Final  Report.  The  SBIR  technology  extended  the  application’s  capabilities  considerably  by 
including  the  SBIR  features  of  linked  Lotus  Notes  databases,  defined  workflow-enabled  business 
processes,  and  ad  hoc  support  processes.  Rather  than  serve  as  a  standard  Notes  document,  the 
Project  Summary  form  became  a  workflow-enabled  document  that  included  such  states  as; 

♦  project  proposal, 

♦  project  acceptance, 

♦  assigning  project  leader,  and 

«  leader  agreeing  to  manage  project. 

Training  for  the  FACTS  Tools  team,  C-130  Air  Scoop  team,  and  others  was  held  on  18  February 
1993  at  the  Groupware  Laboratory  at  Armstrong  Labs  at  WPAFB.  The  training  consisted  of 
instruction  in  the  use  of  the  SBIR  workflow  prototype  software  that  was  delivered  and  installed 
earlier  in  the  month.  A  training  manual,  prepared  by  QDM,  was  distributed  to  those  in 
attendance.  Eighteen  people,  representing  several  organizations,  attended  the  half-day  intensive 
trtuning.  In  addition  to  the  two  sponsoring  organizations  (FACTS  Project  Office  —  SM'"’  — 
and  the  Acquisition  Logistics  Branch  of  the  Armstrong  Laboratory  Logistics  Research  Bianch  — 
AL/HRGA),  Headquarters  Air  Force  Materiel  Command  (HQ  AFMC),  and  Aeronautical  Systems 
Center  Technology  Transition  Division  (ASC/SMT)  also  attended  training. 
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The  workflow-enabled  version  of  the  FACTS  Project  Folders  database  was  further  customized 
and  installed  on  the  FACTS  Notes  server.  For  the  most  part,  the  customization  resulted  from 
feedback  regarding  roles  of  team  members  and  how  the  FACTS  process  actually  worked  during 
the  training  session  given  to  the  FACTS  Tools  team  and  others  on  18  February  1993. 

Prototype  users  made  recommendations  for  changes  to  the  system  through  the  “QDM  Feedback” 
form  available  in  the  Lotus  Notes  mailbox  and  the  Project  database.  This  form  was  automatically 
routed  to  QDM,  AL/HRGA,  and  the  Aeronautical  Systems  Command  of  the  Filght  Systems 
Engineering  branch  of  the  Subsystems  System  Program  Office  (ASC/SMEF).  QDM  used  this 
form  to  determine  whether  the  feedback  required  a  change  in  the  prototype,  and  whether  to 
forward  it  as  a  reconunendation  to  AL/HRGA  and  ASC/SMEF.  Negotiations  would  be  held  with 
QDM,  AL/HRGA  and  ASC/SMEF,  if  necessary.  The  final  decision  would  be  documented  and 
sent  to  the  originator  of  the  feedback,  as  well  as  the  other  process  participants. 

Installing  Prototype  Graphical  Front-End  at  the  Fasteners,  Actuators,  Connectors, 
Tools,  and  Subsystems  Office  —  June,  1993 

Training  the  Fasteners,  Actuators,  Connectors,  Tools,  and  Subsystems  Office  in 
Use  of  Graphical  Front-End  —  June,  1993 

In  June  1993,  we  installed  the  Graphical  User  Interface  module.  Testing  of  the  prototype  began 
then  and  resulted  in  the  FACTS-specific  modifications  discussed  earlier.  During  the  prototype 
installation  period,  we  also  trained  the  FACTS  office  in  the  administration  and  use  of  the 
Graphical  User  Interface.  We  trained  the  administrators  on  site.  The  FACTS  Tools  team  was 
trained  in  the  prototype  GUI  as  end  users.  We  also  provided  hardcopy  training  and  installation 
material  for  the  FACTS  Tool  Team. 

Throughout  this  stage  of  the  effort,  we  continued  to  respond  to  feedback  regarding  both  the  Front 
End  Prototype  and  the  Workflow  Prototype  in  person,  at  our  training  review,  and  in  the  feedback 
database. 

During  and  after  the  GUI  training  session,  QDM  helped  answer  questions  and  address  concerns 
relative  to  the  Process-Oriented  Front  End.  Once  the  FACTS  Tools  team  began  to  use  each 
system,  the  overall  tone  of  this  feedback  was  one  of  excitement  about  the  possibilities  that  such  a 
Front  End  presented.  However,  the  team  began  to  use  the  system  only  after  a  seven-month  delay 
during  which  little  beta  testing  of  either  prototype  occurred.  This  delay  was  largely  due  to  a 
top-down  attitude  in  the  FACTS  office  that  considered  this  SBIR  effort  and  its  technological 
products  to  be  only  an  ancillary  concern  and  not  within  the  realm  of  mainstream  business. 

Despite  this  attitude,  when  the  FACTS  office  did  finally  get  around  to  testing  the  system,  it 
realized  that  both  the  workflow  module  and  the  GUI  could  be  customized  to  address  its  specific 
needs  and  integrated  into  a  real-time  management  system.  Feedback  such  as  this  resulted  in  the 
redirection  of  the  SBIR  effort  away  from  the  generic  QC/MP  tools  and  toward  FACTS-specific 
installations  of  the  workflow  and  GUI  modules  previously  described. 
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Install  and  Train  Users  in  the  Use  of  the  Fasteners,  Actuators,  Connectors,  Tools, 
and  Subsystems-specific  Graphical  Front-End  at  the  Fasteners,  Actuators, 
Connectors,  Tools,  and  Subsystems  Office  —  October-December,  1993 

As  a  result  of  the  test  bed’s  request  for  expanded  fiinctionality,  we  installed  and  continued  to  test 
and  refine  the  updated  Workflow  and  Graphical  User  Interface  modules  at  the  test  bed.  The 
enhancement  of  these  portions  of  the  technology  grew  as  a  result  of  the  FACTS  request  for  more 
robust  production  teclmology  that  has  been  tailored  to  address  specific  business  situations.  We 
are  providing  FACTS  with  technology  that  will  continue  to  evolve  as  its  business  requirements 
continue  to  evolve. 

We  are  providing  informal  administration  training  (technical  transfer-type  training)  as  we  install 
the  enhanced  portions  of  the  effort.  End  user  training  has  been  previously  provided;  any  further 
end  user  training  can  be  incorporated  with  basic  Lotus  Notes  training.  The  contract  modification 
was  entirely  a  technical  development  effort  and  did  not  provide  for  additional  training. 

The  Path  to  a  Better  System 

Throughout  the  development  of  the  Groupware  System  for  Multidisciplinary  Participation,  QDM 
has  learned  much  and  has  applied  these  lessons  to  the  process  of  improving  and  refining  the 
system.  Critical  decisions  such  as  the  defirution  of  the  methodology  for  teamwork,  the  selection 
of  the  groupware  platform  and  workflow  system  in  which  to  implement  this  methodology,  the 
integration  of  the  tools  module  into  the  process  analysis  capabilities  of  the  workflow  system  and 
GUI,  and  the  determination  of  an  appropriate  pilot  environment  in  which  to  test  the  system  all  had 
a  great  deal  of  impact  on  the  development  and  maturation  of  the  system  and  the  SHIR  effort  as  a 
whole.  The  results  of  each  of  these  decisions  are  discussed  in  the  next  section  of  this  Final 
Report. 
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DISCUSSION  OF  RESULTS 


This  Phase  II  SBIR  efifort  has  resulted  in  the  creation  of  iimovative  new  technologies  and  in  the 
application  and  integration  of  emerging  and  existing  technologies  in  powerful  new  ways.  While 
these  results  are  exciting  from  a  technological  standpoint,  the  real  gains  have  been  on  the  human 
side.  People  are  now  working  together  in  ways  never  before  possible,  and  knowledge  and 
expertise  can  be  contributed  and  shared  throughout  the  organization.  Activity  can  be  tracked  and 
monitored  at  all  levels,  from  personal  productivity  to  organization-wide  executive-level  views. 
Geographical  and  interdepartmental  barriers  to  communication  and  teamwork  have  been 
effectively  eliminated. 

These  gains  would  not  have  been  possible  if  not  for  QDM’s  realization  that  technology  cannot 
drive  the  organization.  Phase  n  of  this  SBIR  effort  has  clearly  demonstrated  the  importance  of  a 
synergistic  relationship  between  an  organization's  culture  and  technology.  Just  as  the  culture  can 
be  influenced  by  the  effective  introduction  and  use  of  groupware,  workflow,  and  process  analysis 
tools,  so  can  the  design  and  implementation  of  the  technology  be  driven  by  the  needs,  desires,  and 
work  habits  of  the  culture. 

One  of  the  difficulties  in  discussing  the  results  of  a  groupware  system  is  that  some  of  the  positive 
effects  that  are  achieved  are  not  easily  measured.  Ronni  Marshak,  a  respected  industry  analyst,  in 
her  recent  article  “What  is  Productivity,  Anyway?,”  discusses  the  difficulty  of  initially  quantifying 
the  results  of  a  successfully  implemented  groupware  system.  She  proposes  the  following 
approach  to  gaug^g  results:  “Rather  than  measuring  the  amount  of  work  that  can  get  done,  I 
think  we  should  measure  the  quality  of  the  work  that  gets  done”  (Marshak,  1993). 

Marshak  uses  the  analogy  of  word  processing  software  to  make  her  point.  Word  processors  do 
not  make  people  faster  typists,  but  they  make  editing  and  reprinting  much  faster,  and  they  greatly 
improve  the  quality  of  the  finished  product.  It  is  no  longer  acceptable  to  submit  a  proposal  that 
has  correction  fluid  applied  over  its  typographical  errors.  Marshak  predicts  similar  results  from 
the  advent  of  groupware;  “I  believe  that  there  will  be  similar  improvement  in  the  quality  of  group 
work.  Actually,  the  improved  quality  could  be  even  greater  —  after  all,  the  whole  is  greater  than 
the  sum  of  its  parts.  Productive  individuals  working  together  should  result  in  even  more 
productive  groups"  (Marshak,  1993). 

However,  as  we  pointed  out  in  our  initial,  critical  assertion,  these  benefits  are  not  automatic. 

They  are  a  product  of  two  equally  important  factors:  a  responsive,  well-designed  system,  and  an 
effective,  culturally-sensitive  implementation  of  that  system.  If  a  group-oriented  technology, 
regardless  of  its  level  of  technical  sophistication,  runs  counter  to  the  culture  and  goals  of  the 
organization,  it  is  destined  to  fail. 

The  following  sections  will  detail  the  results  of  our  efforts  and  decisions  during  the  design, 
creation,  and  implementation  of  the  Groupware  System  for  Multidisciplinary  Participation,  as 
depicted  in  Figure  30.  These  results  are  powerful  technological,  methodological,  and  cultural 
lessons  that  have  provided  concrete  benefits  to  both  our  SBIR  and  our  commercial  efforts  in  the 
past  and  will  continue  to  do  so  into  the  future. 
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Figure  30 

The  Groupware  System  for  Muttidisciplinary  Participation  developed  in  a  series  of 
interconnected  modules.  Results  were  achieved  and  lessons  learned  from  each  individual 

module  as  well  as  the  system  as  a  whole. 

MODULAR  ARCHITECTURE  OF  THE  SBIR  SYSTEM 

The  Selection  of  Lotus  Notes  as  the  Groupware  Platform 

As  explained  earlier,  QDM  selected  Lotus  Notes  as  the  groupware  platform  on  which  to  develop 
the  System  for  Multidisciplinary  Participation.  This  selection  was  made  a  few  short  months  after 
Lotus  Notes  had  first  been  released  in  late  1989,  and  was  based  on  QDM’s  assessment  that  Lotus 
Notes’  features  and  architecture  would  provide  all  the  technological  components  for  our  robust 
system’s  architecture. 

Four  years  later,  the  rest  of  the  software  industry  and  end-user  community  is  realizing  what  QDM 
had  accurately  deduced  fi'om  the  begiiming.  Lotus  Notes  is  now  the  standard  against  which  all 
other  groupware  platforms  Avill  be  measured.  Indeed,  Lotus  Notes  is  so  far  ahead  of  the  field  as 
to  have  no  direct  competition  at  this  writing.  No  other  product  can  match  Lotus  Notes’  features 
and  flexibility  as  a  groupware  application  development  platform. 

The  FACTS  office  is  now  one  of  the  many  organizations  across  the  globe  that  is  realizing  direct 
benefits  from  the  use  of  the  Lotus  Notes  platform.  Effective  Notes  applications,  especially 
workflow-enabled  ones  such  as  Quality  At  Work,  are  enabling  individuals  and  workgroups  at 
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FACTS  and  throughout  the  private  sector  to  comr;  unicate  and  share  information  in  ways  never 
before  possible.  Lotus  Notes’  unique  public  spaces  encourage  and  enable  organizational-wide 
input,  allowing  more  people  to  apply  and  share  their  expertise  across  a  wider  range  of  projects. 
Rather  than  work  in  a  vacuum  of  personal  responsibility,  users  are  empowered  with  the  ability  to 
peruse  the  activities  of  the  entire  organization  and  contribute  their  expertise  to  all  appropriate 
processes.  By  providing  such  capabilities  as  these,  Lotus  Notes  is  steadily  redefining  and 
extending  the  definition  and  benefits  of  teamwork. 

Lotus’  competitors,  such  industry  giants  as  Microsoft  and  Oracle,  are  scrambling  to  come  up  with 
an  answer  for  the  Lotus  Notes  phenomenon.  They  realize  that  Lotus  Notes’  power  as  a 
communication  and  teamwork  platform  has  enabled  it  to  continue  to  dominate  the  market  it  has 
defined. 

Workflow  Lessons  Learned:  Technological  Tools  for 

Culture-Defined  Needs 

Designing  and  implementing  workflow  solutions  during  this  SBIR  effort  has  led  us  to  some 
revelations  about  what  this  technology  is  and  how  best  it  can  be  used.  Through  lessons  learned 
during  this  SBIR  effort,  QDM  has  broadened  the  entire  concept  of  workflow  and  discovered  the 
best  ways  of  applying  it. 

A  Spectrum  of  Solutions 

When  QDM  first  began  working  with  workflow,  the  technology  was  young,  and  the  concept 
behind  it  was  quite  specific.  The  spectrum  of  workflow  solutions  at  this  time  consisted  of  a  single 
point:  production  workflow.  “Workflow”  in  the  technological  sense  had  only  one  meaning;  the 
software  automation  of  a  sequence  of  predefined  steps 

Implementing  this  type  of  workflow  in  our  SBIR  pilot  environments  illustrated  to  us  both  the 
power  and  limitations  of  this  technology.  While  production  workflow  proved  extremely  useful  in 
performing  its  intended  function,  a  technological  void  existed  in  automating  processes  that  were 
less  structured  or  more  loosely  defined.  QDM  invented  ad-hoc  workflow  tools  to  fill  this  need 
and,  in  so  doing,  broadened  the  definition  of  “workflow”  to  include  a  spectrum  of  solutions  that  is 
now  capable  of  automating  every  type  of  process,  from  the  most  complex,  rigidly  defined  process 
to  the  most  basic,  elemental  ad-hoc  functions  that  pervade  daily  business. 

Our  SBIR  efforts  have  also  taught  us  the  basic  lesson  that  the  type  of  workflow  introduced  into 
an  organization  must  match  the  type  of  process  it  is  automating.  Further,  and  at  an  even  more 
elemental  level,  we  have  learned  that  the  nature  of  an  organization’s  processes  (eg.,  the  degree  of 
flexibility  and  variation  required  to  accommodate  the  culture  of  the  organization)  is  directly  driven 
by  the  nature  of  the  organization  itself  Thus,  the  first  step  and  primary  factor  in  determining  a 
suitable  workflow  solution  for  an  organization  is  to  examine  the  organization  itself 
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striking  a  Culturai  Nerve  with  Workflow 

Because  workflow  is  mapped  so  closely  to  processes,  and  processes  mapped  so  closely  to 
organizational  culture,  the  selection  and  implementation  of  a  workflow  system  has  an  immediate 
and  powerful  cultural  impact.  If  this  impact  is  generally  positive,  an  organization  can  expect  large 
improvements  in  the  areas  of  operations  and  productivity.  A  negative  initial  reaction  could  result 
in  wholesale  rejection  of  the  technology,  and  the  effort  that  went  into  designing  and  implementing 
it  would  be  wasted.  Given  these  stakes,  it  is  vital  to  determine  an  organization’s  cultural  needs 
and  preferences  prior  to  designing  a  system  that  supports  them. 

Our  SBIR  pilots,  as  we  will  discuss  m  detail  later  in  this  section,  taught  us  many  of  these  lessons. 
Implementing  a  production  workflow  system  in  an  environment  that  was  not  ready  for  it  (namely, 
PIBO)  resulted  in  some  of  the  unpleasant  ramifications  discussed  above.  These  consequences  do 
not  constitute  an  indictment  of  the  PIBO  organization;  they  merely  indicate  that  the  type  of 
workflow  selected  for  the  system  did  not  accurately  reflect  the  culture  of  the  organization  at  that 
time.  PIBO  was  in  a  state  of  flux  during  this  period;  it  was  constantly  being  redefined  by 
organizational  realignments  within  the  Air  Force.  These  cultural  factors  made  the  complex  PIBO 
process  much  more  subject  to  change  than  it  might  have  been  otherwise  and,  thus,  made  the 
production  workflow  system  unduly  restrictive  in  this  environment.  This  clash  between  culture 
and  technology  proved  to  be  a  valuable  lesson  for  QDM  in  the  design  of  future  pilot  and 
commercial  systems. 

As  a  result  of  the  incompatibility  of  this  type  of  workflow  with  the  organization’s  culture,  and 
because  the  system  arrived  just  as  the  organization  was  being  realigned,  we  found  that  the  custom 
solution  that  we  delivered  to  PESO  was  rarely  used.  The  automation  that  was  relevant  to  the 
PRAM,  RAMTIP,  and  FACTS  oflBces  became  less  so  when  those  organizations  were  separated 
into  different  commanding  divisions. 

A  Common  Denominator 

Despite  the  difficulties  with  our  initial  production  workflow  pilot,  we  learned  many  valuable 
lessons.  Perhaps  the  most  important  of  these  was  that  the  users  of  the  PIBO  production  system 
did  not  reject  the  individual  actions  in  the  workflow  so  much  as  the  forced  sequence  of  these 
actions.  In  fact,  the  sequence  of  events  was  the  only  factor  that  was  continually  changing  as  a 
result  of  organizational  realignments.  The  individual  elements  of  the  process  remained  relevant  to 
the  task  of  getting  the  work  done.  When  we  distilled  the  larger  process  down  into  its 
components,  we  noticed  a  few  common  processes  that  not  only  continually  occurred  within 
PIBO,  but  seemed  relevant  and  pervasive  in  business  in  general.  Such  processes  as  assigning 
action,  gathering  input,  building  consensus,  and  gaining  approval  became  the  building  blocks  for 
ad-hoc  workflow  tools. 

Based  on  our  observations  of  and  feedback  from  the  PIBO  pilot,  we  determined  that  de-coupling 
these  processes  from  the  structure  of  production  workflow  sequencing  "would  provide  a  powerful 
set  of  basic  workflow  tools.  Mapping  these  processes  to  the  Basic  Action  Workflow  was  the  next 
logical  step.  All  of  these  processes  naturally  followed  the  closed-loop  feedback  form  of 
conversation  as  described  by  the  ATI  diagram  (see  Fig.  7).  Our  SBIR  effort  had  taught  us  the 
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vital  lesson  that,  in  order  for  workflow  technology  to  work  effectively,  it  had  not  only  to 
automate  and  streamline  processes  but  to  do  so  in  a  manner  that  users  would  be  willing  and  eager 
to  use. 

These  ad-hoc  tools  filled  the  basic  needs  of  organizations  looking  to  automate  and  streamline  their 
most  elemental  processes.  The  tools  complement  a  production  workflow  envirorunent  well;  they 
can  be  used  on  an  as-needed  basis  when  situations  arise  in  the  course  of  daily  business. 

Selectively  applying  these  tools  lets  users  build  complex  processes  based  not  on  a  pre-defined  set 
of  rules  and  conditions,  but  on  the  specific,  highly  fluid  demands  of  a  dynamic  workplace.  As 
users*  needs  change,  they  may  select  and  apply  the  tools  or  combinations  of  tools  that  will  allow 
them  to  achieve  the  desired  results  (as  shown  in  Figure  31.) 

Forms-Based,  Ad-Hoc  Workflow 

These  tools,  when  added  to  the  baseline  workflow  system,  increase  both  the  functionality  and  the 
potential  palatability  of  the  system.  These  tools  form  the  nucleus  of  the  commercial  product. 
Quality  At  Work,  that  resulted  directly  from  technologies  developed  as  part  of  this  SBIR  effort. 
As  mentioned,  these  technologies  are  to  a  large  extent  the  products  of  lessons  learned  from  our 
earliest  pilots.  The  initial  user  rejection  of  the  production  workflow  system  at  PIBO  gave  us 
insights  into  the  types  of  technologies  that  would  work  in  this  environment. 


Ad-hoc  tools  complement  a  production  workflow  environment  by  automating  the  types  of 
common  processes  critical  to  the  accomplishment  of  larger  objectives,  but  difficult  to  fully 

anticipate. 

Providing  tools  to  users,  rather  than  structuring  and  automating  a  rigid  process,  smoothes  the 
transition  to  the  workflow-enabled  system  and  culture.  Users  will  use  the  tools  as  they  see  fit, 
applying  the  system  to  the  ever-changing  challenges  of  daily  business.  For  more  fluid  processes, 
this  plan  is  much  more  culturally  palatable  than  the  strict  recipe  mandated  by  production 
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workflow.  These  ad-hoc  tools  were  designed  and  rolled  out  in  a  much  more  culturally  seamless 
fashion  in  the  FACTS  office  and,  as  a  result,  were  much  more  widely  accepted. 

In  the  workflow  domain,  these  simple,  powerful  tools  represent  and  automate  ad-hoc  and 
administrative  processes.  For  instance,  the  act  of  asking  an  associate  to  do  a  simple  task  is  one  of 
the  most  basic,  pervasive  transactions  in  the  business  world.  A  tool  (such  as  the  QAW  Action 
Item)  which  automates  and  monitors  the  assignment,  progress,  and  successful  completion  of  such 
ad-hoc  activities  could  be  effectively  applied  to  the  full  spectrum  of  business  concerns. 

Similarly,  tools  such  as  the  Quality  At  Work  Brainstorm,  Opinion  Poll,  and  Request  Approval 
represent  and  embody  common  ad-hoc  and  administrative  practices  —  soliciting  ideas  and  input, 
building  consensus,  and  gaining  the  approval  of  superiors  —  that  occur  across  a  broad  range  of 
organizations.  These  tools,  together  with  the  Action  Item,  are  the  basic  building  blocks  with 
which  individuals  may  construct  more  complex  processes.  QDM  actively  encourages  users  to  do 
so  by  making  each  tool  so  simple  and  powerful. 

Consistent  with  QDM’s  definition  of  Management  Technology,  these  technological  tools  embody 
and  seamlessly  implement  effective  business  practices  into  the  workplace.  Because  these  practices 
take  the  form  of  simple  workflow  tools  that  are  used  daily,  they  “come  in  under  the  cultural  radar 
system”  of  the  organization.  Merely  by  giving  people  simple,  powerful  tools  with  which  to 
perform  their  work,  an  organization  may  implement  “best  practices.” 

Forms-based  Workflow  in  the  Fasteners,  Actuators,  Connectors,  Tools,  and 
Subsystems  (FACTS)  Office 

Based  on  lessons  learned  during  our  production  workflow  experience  at  PEBO,  we  concentrated 
our  efforts  on  a  forms-based  workflow  solution  for  the  FACTS  office  because  we  recognized  that 
their  dynamic  culture  would  demand  such  flexible  tools.  We  eliminated  the  restrictive  aspects  of 
the  technology  and  successfully  installed  a  forms-based  solution.  As  discussed  earlier,  these 
forms-based  tools  gave  users  additional  flexibility  and  made  no  strict  demands  about  how  they 
should  be  used. 

We  assumed  that,  because  these  tools  were  more  suited  to  their  environment  and,  thus,  more 
culturally  palatable,  this  new  system  would  be  more  easily  accepted  and  widely  used.  However, 
we  soon  discovered  that  even  this  flexible  system  was  not  being  satisfactorily  embraced  by  the 
user  community.  Other  cultural  factors  were  not  being  sufficiently  addressed  in  the  FACTS 
office,  preventing  the  pilot  fl'om  reaching  critical  mass  and  gaining  momentum  and  acceptance. 

One  of  the  most  powerful  factors  in  this  lack  of  momentum  was  the  instability  at  the  top  of  the 
FACTS  office;  it  is  now  working  under  its  fourth  colonel  since  the  beginning  of  the  effort. 
Because  of  these  frequent  shifts  in  leadership,  QDM  was  unable  to  establish  a  consistent  level  of 
management  commitment  in  the  technology. 

This  instability  was  exacerbated  by  a  lack  of  training  and  awareness  in  workgroup  processes.  If 
team  members  are  not  fully  aware  of  business  processes,  it  is  more  difficult  to  realize  the  benefits 
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of  a  workflow  system.  Users  who  are  not  fully  aware  of  how  a  process  works  are  much  less 
likely  to  notice  and  appreciate  improvements  in  the  way  that  process  is  performed. 

A  driving  factor  in  this  lack  of  process  awareness  was  the  amount  of  turnaround  in  the  FACTS 
office,  not  just  at  the  management  level,  but  throughout  the  organization.  Technical  and  support 
staff  members  came  and  went,  creating  inconsistencies  at  all  levels  and  continually  restocking  the 
organization  with  personnel  who  were  unfamiliar  with  its  culture,  processes,  and  tools. 

Recently,  under  its  current  leadership,  the  FACTS  office  began  to  use  the  pilot  system  in  earnest 
and  realized  the  extent  to  which  these  technologies  could  be  highly  useful.  Both  the  workflow 
system  and  the  Process-Oriented  Front  End  were  recognized  as  tools  which  could  streamline 
operations  and  increase  individual  and  workgroup  productivity.  Users  were  made  aware  of  the 
degree  to  which  FACTS-specific  processes  could  be  mapped  to  these  technologies,  and  with  this 
awareness  came  the  opportunity  for  the  culture  of  the  FACTS  office  to  drive  the  design  of  the 
groupware  system. 

Real,  practical  needs  drove  the  design  of  the  system  and  ensured  its  current  and  future 
applicability.  The  Groupware  System  for  Multidisciplinary  Participation  is  currently  in  use  in  the 
FACTS  office,  helping  manage  projects,  keep  commitments,  and  generate  the  metrics  needed  to 
produce  monthly  status  reports.  In  addition  to  streamlining  operations,  the  system  now  allows 
FACTS  to  capture  and  examine  records  of  past  performance  and  to  build  future  successes  on  the 
lessons  learned  from  these  records. 

By  modeling  the  system  after  the  culture,  QDM  and  the  FACTS  office  have  worked  together  to 
ensure  that  the  SBIR  technology  is  implemented  into  a  system  that  is  liked  and  used  by  the 
community.  Building  this  system  with  flexible  tools  as  opposed  to  hard-coded,  strictly  defined 
processes  ensures  that  it  will  remain  relevant  in  the  future. 

Ad-hoc  Tools:  A  Smart  First  Step  to  a  Workflow-Enabled  Culture 

The  “toolbox”  approach  also  helps  ensure  the  solution  will  remain  responsive  to  the  needs  of 
individuals  and  workgroups.  Because  these  tools  are  simple  and  easy  to  use,  they  may  be  added 
to  or  removed  from  the  toolbox  as  necessary.  Users  have  the  power  to  dictate  the  relative 
importance  of  each  tool  merely  by  using  it. 

This  implementation  also  allows  for  the  inevitable  variations,  however  slight,  in  the  ways  that 
different  workgroups  perform  similar  tasks.  The  fact  that  two  workgroups  perform  a  similar  task 
slightly  differently  is  not  an  indictment  in  itself  —  it  is  merely  an  indication  that  each  is  remaining 
sensitive  to  the  dynamics  at  work  in  the  group  and  the  highly  specific  sets  of  circumstances  that 
dictate  proper  action.  These  variations  speak  volumes  about  the  way  that  an  organization 
achieves  its  business  goals  and,  for  that  reason,  are  worth  capturing  and  examining. 

Such  variation  does  not  rule  out  a  structured  production  workflow  system.  In  fact,  analyzing 
strings  of  ad-hoc  processes  can  lead  to  the  effective  design  and  implementation  of  a  production 
workflow  system.  In  many  cases,  a  workflow  toolbox  can  be  a  smart  first  step  on  the  path  to 
production  workflow  by  helping  an  organization  automate  processes  based  on  past  successes,  not 
on  ethereal  analyses. 
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A  critical  factor  when  analyzing  user  patterns  should  be  the  degree  of  variation  between 
workgroups.  The  way  different  workgroups  apply  similar  tools  to  similar  tasks  could  be  the  key 
to  the  continued  success  of  the  systems  solution.  Figure  32  depicts  two  possible  patterns  of  use 
that  nught  develop  in  a  “workflow  toolbox”  environment. 


Figure  32 

Graph  displaying  two  possible  degrees  of  variation  in  the  way  different 
workgroups  perform  similar  processes.  Little  variation  (top  curve)  indicates 
a  possible  candidate  environment  for  a  strict  production  workflow  system,  while  more 
variation  (bottom  curve)  demonstrates  the  continued  need  for  ad-hoc  tools. 

If  little  variation  is  noticed  in  the  way  different  workgroups  perform  a  given  process  (as  illustrated 
in  the  top  curve),  it  might  be  best  for  the  organization  to  fully  automate  that  process  by  locking  in 
to  a  structured  production  workflow  system.  If  past  experience  proves  that  the  steps  involved  are 
rigidly  defined  across  the  full  bandwidth  of  users  and  not  prone  to  change,  a  custom  production 
workflow  solution  would  effectively  process  the  flow  of  work  along  these  structured  lines.  The 
organization  t^l  have  chosen  production  workflow  as  a  result  of  observed  past  patterns  of 
success,  not  as  a  result  of  expensive,  ethereal  analysis  and  process  design.  In  combination  with 
production  workflow  systems,  the  workflow  toolbox  will  fill  the  ad-hoc  gaps  in  the  process, 
nicely  complementing  the  predefined  aspects  of  the  process. 

If,  on  the  other  hand,  a  fair  amount  of  variation  is  noticed  in  the  way  different  workgroups  use  the 
tools,  (as  in  the  bottom,  flatter  curve)  production  workflow  would  have  the  damaging  effect  of 
forcing  all  workgroups  to  conform  to  one  given  work  pattern.  The  fact  that  different  workgroups 
are  not  performing  a  given  process  in  precisely  the  same  way  every  time  does  not  mean  that  each 
workgroup  is  not  acting  efficiently  and  effectively.  Indeed,  in  today’s  dynamic  business 
environments,  concrete,  structured  “standard  procedures”  are  much  more  the  exception  than  the 
rule. 

Examining  past  practices  can  also  lead  to  the  continued  refinement  of  the  toolbox  to  ensure  that  it 
remains  maximally  useful.  Corporate  management  and  MIS  can  observe  patterns  of  use  among 
and  between  user  workgroups  to  ensure  that  the  system  is  effectively  responding  to  the  needs  of 
the  users.  As  these  patterns  continue  to  emerge  and  develop,  the  toolbox  can  be  expanded  and 
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tailored  so  that  the  workflow  solution  continues  to  meet  the  demands  of  the  users  and  business 
situations  into  the  future.  For  example,  if  a  group  is  constantly  using  Action  Items  to  request  that 
parts  be  shipped  to  a  client  site,  a  customized  “Send  Materials”  form  can  be  easily  created  from 
the  baseline  Action  Item.  The  users  dictate  the  design  of  the  technology,  rather  than  the 
technology  dictating  the  work  habits  of  the  users. 

All  of  these  workflow  and  groupware  “lessons  learned”  were  instrumental  in  the  design  and 
release  of  the  commercial  software  product  Quality  At  Work.  Just  one  year  into  this  effort, 

QDM  was  able  to  apply  the  technology  we  developed  and  the  knowledge  we  gained  to  the 
successful  launch  of  a  commercial  software  product.  Quality  At  Work  isxurrently  in  use 
worldwide  by  businesses  and  organizations  of  all  sizes,  including  a  Global  SO  con^omerate  (Asea 
Brown  Boveri  or  ABB),  a  world  renowned  consulting  firm  (Arthur  Andersen),  and  a  large 
Government  agency  (GSA).  This  widespread  applicability  is  consistent  with,  and  validation  of, 
our  assertions  in  our  initial  proposal  as  to  the  commercial  viability  of  these  technologies. 

Graphical  User  Interface/Process  Analysis  Tools 

The  design  of  the  process  analysis  tools  and  the  Graphical  Front-End  into  which  they  were  built 
was  similarly  user-driven.  This  development  effort  resulted  at  first  in  a  flexible,  generic  Front  End 
and  then,  based  on  positive  feedback  and  interest,  in  a  powerful  tool  that  our  SBER.  customer  is 
using  not  only  to  analyze  its  processes  but  also  to  streamline  the  creation  of  PMR  Reports.  The 
SBIR  technology  is  being  used  not  in  a  sterile  test  environment,  but  in  the  rigorous  course  of  daily 
business  to  help  management-level  personnel  get  their  jobs  done. 

Here  again,  the  focus  of  the  development  effort  was  not  on  the  technology  but  on  the  business 
need  that  the  technology  could  address.  In  this  instance,  the  specific  need  was  for  a  tool  that 
would  provide  a  management-level  summary  of  data  collected  from  the  workflow  module.  Lotus 
Notes  itself  could  not  adequately  collect  and  graphically  display  data  across  the  entire  spectrum  of 
the  workflow  module;  we  needed  a  separate  development  environment. 

Our  search  for  an  appropriate  development  environment  for  the  Graphical  Front  End  is  testimony 
to  the  fact  that  the  scope  of  business  solutions  is  limited,  not  by  the  technology  available,  but  by 
the  intelligence  with  which  the  technology  is  applied.  When  the  Notebook  environment  proved 
unsuitable  for  the  GUI  effort,  numerous  other  candidate  environments  were  available.  QDM  had 
only  to  explore  these  alternatives  and  settle  on  the  most  appropriate  tool.  There  was  and  is  plenty 
of  available  technology  with  which  to  craft  powerful  business  solutions,  but  it  is  impossible  to  do 
so  without  a  thorough  understanding  of  the  culture  and  goals  of  the  organization. 

This  understanding  of  the  needs  and  goals  led  to  the  redirection  of  the  remainder  of  the  SBER 
effort.  As  discussed,  the  FACTS  office,  upon  using  the  prototype  GUI  and  realizing  its  power 
and  potential,  asked  that  we  customize  the  prototype  to  reflect  FACTS-specific  metrics.  QDM’s 
consistent  attention  to  the  changing  needs  of  our  SBIR  customer  resulted  in  the  custom-fit 
solution  that  is  detailed  at  length  earlier  in  this  report.  The  FACTS  office,  by  providing  feedback 
throughout  the  process,  received  a  solution  that  displays  precisely  the  graphs  and  metrics  that  the 
office  needs  and  uses.  The  Front  End,  now  that  it  embodies  and  displays  FACTS-specific 
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processes  from  the  perspective  of  FACTS-specific  metrics,  has  gained  office-wide  acceptance  as  a 
powerfril,  useful  technological  tool. 

CONCLUDING  REMARKS 

QDM’s  critical  assertion  upon  entering  this  Phase  II  effort  was  that  technology  cannot  drive  an 
organization  —  it  must  be  sensitive  and  responsive  to  the  culture,  needs,  and  goals  of  the 
organization.  This  assertion  affects  every  aspect  of  the  implementation  of  technology  into  the 
workplace,  from  the  initial  design  of  the  system  to  the  way  it  is  introduced  to  its  end  users.  Three 
crucial,  interrelated  factors  govern  the  successful  roll-out  of  any  technology  within  an 
organization.  They  are  as  follow. 

*  An  Understanding  of  the  Culture  of  the  Organization 

*  A  Technology  Designed  to  Reflect  and  Support  this  Culture 

*  An  Effective  Introduction/Implementation  into  the  Workplace 


Over  the  course  of  this  SBIR  effort,  and  through  the  release  of  the  commercial  software  product 
that  resulted  from  the  SBIR  technology  (Quality  At  Work),  QDM  has  refined  its  knowledge  of 
each  of  these  factors.  We  have  not  only  invented  groundbreaking  technology;  we  have 
discovered  the  best  ways  to  introduce  this  technology  such  that  its  full  power  and  potential  is 
realized  by  the  user  community.  We  now  know  not  only  what  makes  a  system  design  intelligent, 
but  also  what  makes  technology  culturally  palatable  and  what  makes  an  implementation  scheme 
effective. 


Understanding  the  Culture  of  the  Organization 

In  order  to  select  the  proper  workflow  system  for  an  organization,  it  is  critical  to  understand  the 
nature  of  its  processes.  However,  as  we  have  stated  previously,  it  is  not  possible  to  gain  a  full 
understanding  and  appreciation  of  an  organization’s  processes  without  first  studying  the 
organization  itself  The  culture  of  the  organization  defines  the  nature  of  its  processes.  Thus,  the 
first  step  in  selecting  a  workflow  solution  for  an  organization  is  to  classify  the  culture  of  the 
organization  on  the  “spectrum  of  flexibility,"  as  illustrated  in  Figure  33. 

Nature  of  Organization/  Defined/Stable/Procedural  Flexible/In  Flux/Dynamic 
Nature  of  Processes 


Figure  33 

The  “spectrum  of  flexibility” 


An  organization’s  location  on  this  spectrum  is  a  product  of  a  combination  of  factors: 
management  styles,  personalities  of  personnel,  awareness  of  processes,  the  percentage  of  work 
performed  by  “knowledge  workers”  (e  g.  the  degree  to  which  ad-hoc  decision  making  affects  the 
process.  Is  the  emphasis  on  input  or  throughput?),  and  external  trends  such  as  the  prevailing 
business  climate  or  industry  trends.  As  these  factors  change  over  time,  the  organization’s  location 
on  the  spectrum  will  adjust  accordingly.  For  example,  a  conunercial  bank  is  ordinarily  a  very 
stable,  procedural  organization.  Standard  practices  are  generally  established  and  managers  and 
team  members  alike  are  comfortable  with  following  them,  because  these  practices  are  well  known 
and  represent  the  best  way  to  get  the  job  done.  However,  during  the  turbulent  economic  climate 
of  the  1980s,  many  banks  were  in  a  state  of  flux  because  of  potential  mergers,  fluctuating  rates, 
and  other  similar  situations.  These  external  factors  pushed  these  banks  closer  to  the  right  end  of 
the  spectrum. 

In  addition  to  the  flexibility  factor,  intelligent  system  design  also  involves  simplicity  and  ease  of 
use;  a  system  cannot  be  effective  if  it  is  a  burden  to  learn  and  use.  Well-designed  production 
systems  will  route  forms  and  advance  processes  with  minimal  effort  from  the  user.  Effective 
ad-hoc  tools  should  pervade  the  system  and  be  as  user-fnendly  as  a  standard  electronic-mail 
Memo.  A  Graphical  User  Interface  must  capture  the  metrics  most  relevant  to  a  business  and 
display  them  in  colorful,  user-fnendly  charts.  Browsing  through  a  business’  processes  and  shifting 
level  of  focus  should  be  as  simple  as  clicking  a  button. 


Mapping  the  Technology  to  the  Culture 


Technology  should  reflect  and  support  the  culture  of  the  organization  into  which  it  is  being 
implemented.  With  workflow  solutions,  mapping  the  technology  to  the  culture  is  relatively 
simple,  because  the  nature  and  goals  of  the  spectrum  of  workflow  systems  runs  parallel  to  the 
“spectrum  of  flexibility”  of  organizations  (see  Figure  34).  More  stable,  rigid  organizations  tend  to 
have  more  static  processes  that  are  best  automated  by  production  workflow.  Ad-hoc  tools  in 
these  organizations  are  used  to  “plug  the  gaps”  in  the  production  process.  More  flexible 
organizations  profit  most  from  the  exclusive  use  of  ad-hoc  workflow  tools. 


Nature  of  Organization 
Nature  of  Processes 


Type  of  Workflow 


Defined/Stable/Procedural  Flexible/In  Flux/Dynamic 


Figure  34 

The  "spectrum  of  flexibility"  from  Production  to  Ad-hoc  Workflow 

For  organizations  and  processes  that  are  very  procedural  and  involve  a  defined  series  of  steps, 
production  workflow  could  provide  a  significant  return  on  investment.  However,  our  SBER  effort 
and  pilots  have  demonstrated  that  the  integration  of  ad-hoc  workflow  tools  as  an  introduction  or 
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complement  to  production  systems  can  ease  the  transition  to  production  workflow.  These  more 
flexible,  easy-to-use  tools  can  introduce  and  complement  production  workflow  effectively.  First, 
ad-hoc  tools  can  be  implemented  as  a  smart  first  step  to  a  production  workflow  process.  They 
are  easy  to  use,  and  they  pervade  the  organization,  thus  seamlessly  acclimating  the  users  and 
culture  to  the  concept  of  workflow.  Second,  after  the  tools  are  introduced,  the  ways  in  which  the 
tools  are  a^-pUed  by  users  can  be  captured  and  analyzed,  and  the  processes  that  have  proven  most 
successful  with  the  least  amount  of  user  variation  in  their  performance  (see  Figure  32)  can  be 
automated  with  production  workflow.  Finally,  once  the  production  workflow  process  is  in  place, 
the  ad-hoc  tools  can  continue  to  complement  it  by  streamlining  the  unanticipated  duly  processes 
that  occur  in  support  of  the  larger  process. 

This  evolutionary  paradigm  provides  cultural  benefits  in  addition  to  technological  flexibility. 

QDM  has  learned  that  users  often  resist  the  advent  of  workflow  systems  whose  position  on  the 
workflow  spectrum  does  not  match  the  organization’s  standing  on  the  “spectrum  of  flexibility.” 
Inappropriate  levels  of  structure  (or,  for  that  matter,  flexibility)  create  user  and  management 
resistance  to  the  technology  and  could  lead  to  rejection  of  the  system.  Fitting  the  technology  over 
the  organization’s  culture  and  processes  is  more  palatable  and,  thus,  more  likely  to  be  successful 
than  forcing  the  culture  and  processes  into  the  technology. 

For  this  reason,  QDM  has  developed  a  custom  toolbox  full  of  simple,  powerful,  easy-to-use  tools 
that  can  be  selectively  applied  and  strung  together  to  meet  specific  needs  as  situations  arise  in  the 
course  of  business.  With  these  tools,  users  will  build  processes  naturally.  Rather  than  defining 
the  process  and  having  users  conform  to  it  per  the  production  workflow  paradigm,  this  “toolbox” 
approach  lets  users  use  simple,  powerful  tools  to  construct  complex  processes  based  on  their  own 
specific  work  patterns.  As  these  processes  become  more  common,  the  organization  will  naturally 
slide  toward  the  left  side  of  the  spectrum,  and,  thus,  production  workflow  will  be  an  increasingly 
viable  option  for  those  processes. 

Because  the  Graphical  User  Interface  is  so  tightly  integrated  with  the  workflow  module,  these 
patterns  are  easily  recognized  and  digested  by  the  user  community  through  charts  and  graphs. 
Using  this  piece  of  technology,  uscis  can  continue  to  refine  the  workflow  module  to  ensure  that 
their  organization,  processes,  and  workflow  solution  remain  synchronized  on  the  spectrum. 

An  Effective  Implementation  Scheme 

Matching  the  technology  to  the  organization  is  critical,  but  even  doing  so  perfectly  does  not 
guarantee  success.  Even  the  best-designed,  most  culturally  seamless  application  can  still  fall  flat  if 
it  is  forced  upon  users  against  their  will.  Achieving  management  commitment  and  user  buy-in  is 
absolutely  essential  to  the  successful  roll-out  of  groupware  technology,  especially  across 
multidisciplinary  workgroups  and  cross-functional  teams.  The  technology  or  product  alone  is  not 
enough  to  win  the  battle.  Success  in  the  business  and  cultural  context  comes  from  providing  the 
necessary  system  integration,  planning,  installation,  training,  and  support  components  to  augment 
the  technology  as  “whole  product." 

Our  experiences  with  our  various  pilot  environments  throughout  the  SBIR  effort  have  illustrated 
to  us  the  issues  that  must  be  considered  in  a  successful  implementation.  Having  identified  these 
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issues,  we  devised  strategies  for  anticipating  and  eliminating  them  as  possible  barriers  to  a 
seamless  roU-out. 

Clear  Cultural  Hurdles 

The  results  of  our  pilots  have  demonstrated  to  us  that  the  most  critical  factors  in  the  successful 
implementation  of  a  groupware  solution,  especially  one  involving  workflow  technology,  are 
cultural  in  nature.  The  single  most  important  of  these  factors  is  user  buy-in.  Of  course,  the  most 
effective  path  to  follow  to  this  end  is  the  path  of  least  resistance.  This  path  involves  enga^g  and 
enabling  users  with  powerful,  flexible  tools,  not  mandating  a  standard  way  of  doing  things. 

Our  implementations  of  commercial  workflow-enabled  groupware  products  at  the  Government’s 
GSA  have  demonstrated  to  us  the  paths  of  least  resistance  both  in  design  and  implementation  of 
these  systems.  A  production  workflow  Helpdesk  system  was  forced  upon  technicians  and  support 
staflf  in  the  agency  and,  as  a  result,  was  met  with  widespread  resistance.  A  quality  initiative,  on 
the  other  hand,  was  pursued  with  a  combination  production/ad-hoc  workflow  system.  The  system 
was  introduced  to  users  in  a  dynamic,  interactive  training  session  involving  simulation  and 
role-playing.  As  a  result,  the  user  community  embraced  both  the  system  and  the  quality  initiative 
that  it  supported. 

Train  for  Success 

First  impressions  are  powerful,  and  initial  user  rejection  is  extremely  difficult  to  overcome.  The 
first  inroads  into  engaging  the  users  can  be  made  during  training  sessions.  Training  in 
multidisciplinary  groupware  systems  should  focus  not  on  the  dry  mechanics  of  using  the  system 
but,  rather,  on  the  most  effective  ways  of  applying  the  environment  and  the  system’s  tools  to  the 
challenges  of  daily  business. 

Based  on  our  success  at  the  GSA,  QDM  has  developed  a  unique  approach  to  training  for 
groupware  applications  that  pro\ddes  a  seamless  transition  to  the  environment.  Rather  than 
outlining  the  mechanics  of  using  the  application,  the  training  focuses  on  how  to  weave  the  tools 
into  daily  practice.  Simulation  and  role-playing  are  used  (the  “murder  mystery  approach”)  to 
teach  users  to  apply  the  tools  to  business  situations. 

From  these  training  exercises  comes  an  awareness  of  and  appreciation  for  workgroup  interaction 
and  the  dynamics  of  group  collaboration  and  coordination.  Building  awareness  of  these  processes 
from  the  outset  will  foster  the  acceptance  of  the  system  as  an  ally  in  these  efforts,  not  an  inhibitor 
of  them. 

Identify  and  Target  the  Champion 

This  acceptance  is  further  fostered  by  an  internal  product  champion  who  has  the  vision  and 
leadership  to  realize  the  power  of  the  groupware  environment  and  the  skill  to  choose  and 
implement  a  solution  with  it.  A  champion  who  is  enthusiastic  about  the  technology  can  be  a 
powerful  force  for  change  within  an  organization.  We  witnessed  firsthand  the  importance  of  a 
champion  in  our  experiences  with  the  FACTS  office. 
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Colonel  (Ret.)  Robert  Rissell,  who  initially  sponsored  this  SBIR  effort  and  who  “founded”  the 
FACTS  office,  was  a  true  visionary  who  believed  wholeheartedly  in  the  power  of  these 
technologies  and  their  applicability  to  business  situations.  His  efforts  were  instrumental  in  getting 
this  SBIR  project  funded  and  off  the  ground,  and  his  diligence  and  vision  have  been  rewarded 
with  a  SB^  project  that  warranted  an  “SBIR  Success  Story”  and  resulted  in  a  highly  successful 
commercial  software  product. 

Colonel  Joseph  N.  Kruppa  shared  Rissell’s  vision  and  enthusiasm  and  took  all  necessary  steps  to 
ensure  that  the  effort  continued  to  move  forward.  Under  the  leadership  of  these  two  colonels, 
this  SBIR  effort  flourished.  Lt.  Col.  Sammy  Saliba  has  also  been  instrumental  in  lending  focus 
and  direction  to  this  SBIR  effort  and  the  system  it  produced.  His  process  needs  defined  the  types 
of  metrics  that  would  be  displayed  by  the  GUI  to  ensure  that  the  system  would  be  and  remain 
maximally  useful  to  the  FACTS  office. 

RECOMMENDATIONS 

QDM’s  belief  that  process  improvement  can  only  be  achieved  through  process  awareness  has 
been  consistently  reinforced  throughout  this  SBIR  effort.  Our  research  has  illustrated  to  us  that 
improving  the  ways  people  work  together  is  a  complex  process  that  involves  the  synergy  of 
technolo^cal  and  methodological  concepts,  while  at  the  same  time  uncovering  knowledge  that 
has  helped  us  understand  and  tackle  this  complexity. 

The  knowledge  that  QDM  has  gained  during  this  SBIR  effort  has  enabled  us  to  stratify  the  issues 
at  stake  in  designing  an  effective  Groupware  System  for  Multidisciplinary  Participation.  We  now 
recognize  the  strength  of  the  bond  between  an  organization’s  place  on  the  “spectium  of 
flexibility”  and  the  type  of  workflow  solution  that  will  work  best  for  that  organization.  These 
lessons  were  incorporated  into  a  system  that  both  satisfied  this  SBIR  contract  and,  through 
QDM’s  extensive  effort  independent  of  the  SBIR  grant,  was  successfully  commercialized. 

Recommendation:  Realize  Potential  of  Small  Business  Innovation 

Research  (SBIR)  Investment 

The  demonstrated  commercial  success  of  the  product  proves  that  companies  in  the  private  sector 
recognize  the  benefits  of  this  technology  and  achieve  them  by  using  it.  These  same  benefits  are 
attainable  by  government  organizations,  the  natural  beneficiaries  of  a  successful  SBIR  program. 

These  organizations  can  now  realize  these  benefits  with  a  minimal  investment  and  at  almost  no 
risk.  The  technology  that  makes  teamwork  possible  and  easy  can  and  should  be  widely  applied 
throughout  the  government.  This  flexible,  powerful  technology  is  now,  thanks  to  the  SBIR 
program,  fiilly  developed.  The  opportunities  for  applying  it  within  the  Government  are  unlimited. 
QDM  would  relish  the  opportunity  to  introduce  this  system  into  other  agencies  to  help  them 
realize  the  benefits  of  improved  communication,  teamwork,  and  coordination  that  this  workflow- 
enabled  Groupware  environment  can  provide. 
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step  1:  Obtain  and  Use  the  Software 


The  first  step  on  the  path  to  these  benefits  is  to  obtain  and  actively  use  the  software.  Tools  such 
as  this  that  enable  an  organization  to  improve  processes  are  valuable,  and  investing  in  them  is  an 
investment  in  improving  the  ways  that  people  work  together.  QDM  has  made  this  first  step  easy 
by  providing,  in  Quality  At  Work,  a  cost-effective  point  of  entry  into  the  market.  Because  the 
system  is  inexpensive,  easy  to  use,  and  fully  functional  “out-of-the-box”,  the  entire  organization  is 
able  to  begin  using  it  immediately.  The  fact  that  the  tools  automate  such  pervasive  processes  as 
assigning  action  and  soliciting  input  will  enable  the  workflow  technology  to  begin  to  subtly 
pervade  the  culture. 

The  most  seamless  way  to  introduce  this  technology  to  the  culture  is  with  tools  that  work  in 
user’s  eiectromc  Mail  files.  Most  users  are  comfortable  and  experienced  enough  in  the  use  of 
electronic  mail  to  notice  and  appreciate  the  benefits  that  such  tools  as  Action  Items  and 
Brainstorms  add  to  the  baseline  electronic  Mail  functionality  of  Memo,  Reply,  and  Phone 
Message.  Once  these  benefits  are  achieved  in  the  individual  Mail  files,  the  tools  can  be  rolled  out 
to  public  spaces  such  as  Lotus  Notes  databases,  so  ad-hoc  processes  can  be  generated  from  the 
business  context  of  the  database.  These  processes,  generated  from  databases  but  acted  upon  in 
Mail  files,  can  integrate  the  notions  of  individual  productivity  and  organizational  goals.  These 
tools  and  processes  create  an  interconnected  network  of  coordinated  activity  and  team  members. 

Step  2:  Observe  and  Analyze  Patterns  of  Use:  Extend  System  as  Necessary 

As  the  tools  are  used  throughout  an  organization,  the  patterns  that  develop  should  be  analyzed.  If 
users  are  consistently  using  generic  ad-hoc  tools  for  a  specific  purpose,  creating  a  customized 
version  of  the  tool  thai  is  specific  to  that  purpose  should  be  considered.  If  users  are  consistently 
linking  together  the  same  types  of  ad-hoc  tools,  the  possibility  of  linking  these  processes  together 
in  a  production  workflow  system  should  be  considered. 

The  design  and  use  of  the  worktlow  oolbox  lend  themselves  to  the  implementation  of  this  plan. 

By  analyzing  patterns  of  use,  m.-  aee.Tient  strategists  and  workflow  technologists  may  add,  delete, 
or  refine  the  individual  components  of  the  toolbox  as  dictated  by  past  usage.  For  example,  if 
users  fi-equently  use  a  Quality  At  Work  Action  Item  to  request  that  marketing  collateral  be  sent 
to  new  sales  prospects,  a  custom  “Send  Materials”  Action  Item  may  quickly  and  easily  be 
developed  and  incorporated  into  the  toolbox.  Because  the  tools  are  basic,  the  process  of 
continually  refining  the  toolbox  to  meet  the  needs  of  the  users  is  easy.  The  flexibility  of  the  tools 
and  system  will  ensure  their  applicability  even  as  individuals,  workgroups,  and  the  entire 
organization  rise  to  meet  the  challenges  of  the  future. 

The  workflow  toolbox  approach  effectively  clears  the  cultural  hurdle  to  workflow  because  the 
improvements  are  achieved  through  evolutionary,  not  revolutionary,  change  and  are  achieved  in  a 
manner  that  is  consistent  with  the  culture  of  the  organization.  By  enabling  people  to  apply  the 
tools  to  their  existing  methods  of  getting  the  job  done,  the  toolbox  approach  tailors  the 
technology  to  fit  the  work  habits  of  the  users  rather  than  forcing  users  to  pattern  their  work  habits 
after  the  technology. 


66 


Recommendation:  Provide  Phase  lii  Funding 


The  success  of  our  technologies  and  methodologies  in  both  the  pilot  environment  and  the  business 
world  as  a  whole  demonstrate  the  power  and  relevance  of  the  fruits  of  QDM’s  Phase  II  SBIR 
effort.  One  year  into  the  Phase  n  effort,  we  released  the  commercial  software  product.  Quality 
At  Work,  which  is  now  installed  in  companies  of  all  sizes  worldwide.  The  SBIR  funds  invested  in 
QDM  have  resulted  in  a  “Total  Product”  delivery  mechanism  that  skillftilly  combines  the  power  of 
the  technology  with  the  ability  to  maximize  its  benefits  within  an  organization. 

These  successes  also  evince  the  significant  Phase  III  potential  of  this  effort.  QDM  can  build  on 
this  solid  foundation  of  success  and  continue  both  technolo^cal  and  methodological  progress. 
Indeed,  QDM  has  been  running  its  own  independently  funded  Phase  III  effort  in  parallel  with  our 
SBIR  Phase  n  efforts.  During  these  commercial  efforts,  QDM  has  used  more  than  $1,000,000  in 
funds  for  Research  &  Development,  has  cooperated  with  Lotus  from  the  earliest  beginnings  of 
Lotus  Notes,  and  has  established  and  is  maintaining  distribution  channels  domestically  and 
worldwide. 

Despite  this  success,  many  extraordinary  opportunities  remain.  The  full  potential  of  these 
technologies  and  theories  has  not  been  realized.  With  Phase  III  funding,  the  benefits  from  this 
SBIR  investment  could  be  extended  and  successes  could  continue.  Enhancements  to  both  the 
Workflow  and  GUI  modules  of  the  Phase  II  prototype  would  create  a  compelling  groupware 
application  that  would  be  completely  unique  in  the  current  market.  Nowhere  is  there  a  groupware 
technology  that  so  tightly  integrates  workflow  functionality  with  Graphical  User  Interface 
technologies  for  direct  use  by  end-users. 

The  broad  spectrum  of  applicability  of  our  workflow  module  has  been  demonstrated  both  within 
our  SBIR  pilot  environment  and  in  the  global  commercial  software  marketplace.  Enhancements 
to  this  module,  in  concert  with  a  generalized,  easy-to-use  Graphical  User  Interface  that  reads  and 
displays  workflow  data,  would  build  on  the  successes  of  the  Phase  II  research. 

Recommendation:  Generate  New  Phase  I  Solicitations 

The  success  of  this  Phase  II  effort  and  the  results  of  our  research  during  it  have  opened  up  new 
possibilities  for  Phase  I  SBIR  solicitations.  For  example.  Government  Agency-specific  GUIs 
could  be  created  that  could  give  management  real-time  “Control  Panel”  views  of  the  processes 
specific  to  their  organizations.  In  addition  to  agency-specific  possibilities,  universally  applicable 
object-oriented  technologies  such  as  those  found  in  the  Workflow  and  GUI  modules  of  this  effort 
continue  to  explode  with  possibility.  The  speed  with  which  the  software  industry  is  moving  is 
opening  up  new  opportunities  for  integrating  technology  into  real  business  situations.  QDM, 
through  its  combination  of  technological  savvy  and  methodological  expertise,  has  proven  an 
unparalleled  ability  to  put  technology  to  work. 
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A  Request  from  Quality  Decision  Management 


QDM  is  enthusiastic  about  the  possibility  of  disseminating  the  benefits  of  workflow-enabled 
Groupware  throughout  the  Government.  Other  agencies,  at  minimal  additional  investment,  can 
and  should  be  able  to  take  advantage  of  the  technology  that  was  bom  of  this  SBIR  effort.  The 
benefits  that  these  agencies  would  achieve  would  be  a  rin^ng  endorsement  and  acknowledgment 
not  just  of  this  particular  technology,  but  of  the  SBIR  program  as  a  whole,  and  of  the  foresight  of 
our  contract  management  and  sponsor  for  supporting  this  effort. 

To  facilitate  the  dissemination  of  these  benefits  throughout  the  Government,  QDM  would  like  to 
request  a  Point  of  Contact  with  whom  we  can  maintain  relations  and  through  whom  we  might 
introduce  this  system  to  other  Government  agencies.  We  feel  that  there  is  significant  untapped 
opportunity  for  this  technology  to  help  other  agencies  and  ask  only  for  some  assistance  in 
introducing  and  providing  it  to  them. 

Quality  Decision  Management’s  Future  Plans 

Our  goal  is  to  dominate  the  niche  we  have  created.  The  QDM  concept  of  Management 
Technology  is  going  to  become  increasingly  prevalent  in  the  software  industry  and  the  business 
world  in  general.  When  the  rest  of  the  software  industry  starts  to  realize  the  importance  of  the 
synergy  between  workgroup  technologies  and  cultural  issues,  QDM  will  have  been  integrating  the 
two  concepts  for  years.  We  are  currently  at  the  head  of  the  pack  in  this  area  and  fully  intend  to 
stay  there. 

Obviously,  the  first  step  in  this  strategy  for  the  future  is  to  continue  efforts  in  the  commercial 
software  arena.  Work  is  currently  being  done  on  Quality  At  Work,  the  product  that  grew  out  of 
the  workflow  module  of  the  SBIR  system.  We  are  providing  even  more  robust  and  flexible  tools 
to  our  grovdng  end-user  community  as  well  as  the  capability  to  “Quality  At  IPorAr-enable'’  any 
existing  business  application  in  Lotus  Notes. 

This  capability  is  consistent  with  our  belief  that  technology  should  be  integrated  into  the  culture 
and  practices  of  the  organization,  rather  than  forcing  the  culture  to  submit  and  conform  to  the 
technology.  “Quality  At  IFtirAr-enabling”  applications  is  the  prime  example  of  that  type  of 
integration;  Quality  At  Work  fits  seamlessly  over  existing  Lotus  Notes  applications,  introducing 
the  culture  to  workflow  without  revolutionizing  the  way  the  organization  does  business.  As  we 
have  dettuled  throughout  this  report,  seamless  implementation  of  these  technologies  can  provide 
wide-scale  benefits  to  an  organizations’  communication,  teamwork,  and  productivity. 

QDM  is  thankful  for  the  opportunity  presented  by  the  SBIR  program  to  use  our  skills  and 
innovation  to  help  businesses  worldwide  achieve  these  gains.  We  see  the  opportunity  to  continue 
to  do  so  through  continued  strong  relations  with  both  Government  and  corporate  customers  and 
alliances. 
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Acronyms 

ABB  Asea  Brown  Boveri 

AF  Air  Force 

AL/HRGA  Acquisition  Logistics  Branch  of  the  Armstrong  Laboratory  Logistics  Research 

Branch 

ASC/SMEF  Aeronautical  Systems  Command  of  the  Engineering  FACTS  branch  of  the 
Subsystems  System  Program  Office 

ASC/SMT  Aeronautical  Systems  Center  Technology  Transition  Division 
API  Application  Programming  Interface 

ATI  Action  Technologies,  Inc. 

BTS  Business  Tracking  System 

CE  Concurrent  Engineering 

CSTI  Center  for  Support  of  Technology  Insertion 

DDE  Dynamic  Data  Exchange 

DLA  Defense  Logistics  Agency 

DoD  Department  of  Defense 

FACTS  Fasteners,  Actuators,  Connectors,  Tools,  and  Subsystems 
FY  Fiscal  Year 

GSA  General  Services  Administration 

GUI  Graphical  User  Interface 

HQ  AFMC  Headquarters  Air  Force  Materiel  Command  (HQ  AFMC) 

IDC  International  Data  Corporation 

IFTF  Institute  for  the  Future 

IPD  Integrated  Product  Development 

MP  Management  and  Planning  Tools 

OLE  Object  Linking  and  Embedding 
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Acronyms  (Continued) 


PC 

Personal  Computer 

PI 

Process  Improvement 

PIBO 

Process  Improvement  Bu^ess  Opportunities  Division 

POC 

Point  of  Contact 

PMR 

Program  Monthly  Review 

PRAM 

Productivity,  ReUability,  Availability,  and  Maintainability  Program 

QAW 

Quality  Work 

QC 

Quality  Control 

QDM 

Quality  Decision  Management,  Inc. 

QFD 

Quality  Function  Deployment 

RAMTIP 

Reliability  and  Maintainability  Technology  Insertion  Program 

SAB 

Scientific  Advisory  Board 

SBIR 

Small  Business  Irmovation  Research 

SM 

Subsystems  System  Program  OfBce 

SMGF 

FACTS  Project  OfiBce 

SPC 

Statistical  Process  Control 

SPO 

System  Program  Office 

TQM 

Total  Quality  Management 

TTO 

Technology  Transition  Office 

UI 

User  Interface 

WMS 

Workflow  Management  Server 

WPAFB 

Wright-Patterson  Air  Force  Base 

WYSIWYG 

What  You  See  Is  What  You  Get 
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